- 14 Oct, 2020 2 commits
-
-
Victor Gomes authored
Change-Id: I2f262f4545de9e421310094d0dfab2f6147869b5 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466116Reviewed-by: Junliang Yan <junyan@redhat.com> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70502}
-
Jakob Gruber authored
This is a reland of 16cd5995 Changes since the original CL: generic lowering support for ForInPrepare and ForInNext. Original change's description: > [nci] Prepare JSForInPrepare and JSForInNext for feedback input > > These two operators are still missing feedback collection in generic > lowering (reminder: all operations that collect FB in the interpreter > must also collect FB in generic lowering). > > This CL prepares for that by adding the feedback vector as an input, > and additionally adds node wrappers to improve useability. > > The actual collection logic will be added in a following CL. > > Bug: v8:8888 > Change-Id: I04627eedb2dc237dc4e417091c44d2a95bd98f5f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454712 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70372} Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:8888 Change-Id: Idc294ffd2a24922edd08db6897d32d5724956995 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459373 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70496}
-
- 05 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
We can use tag dispatching to distinguish between the synchronized and non-synchronized accessors. Also eliminated the need of adding explicit "synchronized" in the name when using the macros. As a note, we currently have one case of using both relaxed and synchronized accessors (Map::instance_descriptors). Cleaned up: * BytecodeArray::source_position_table * Code::code_data_container * Code::source_position_table * FunctionTemplateInfo::call_code * Map::instance_descriptors * Map::layout_descriptor * SharedFunctionInfo::function_data Bug: v8:7790 Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70306}
-
- 01 Oct, 2020 1 commit
-
-
Dan Elphick authored
CodeAssembler::Parameter now takes a Type template parameter and performs a checked cast to it. There is also UncheckedParameter which returns a TNode but doesn't check the cast. The original Parameter method is still there as UntypedParameter. Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the cast is performed inside Parameter. Since Parameter is not a macro, this means it cannot see the original expression or its file name and line number. So the error messages are vaguely useful, Parameter<T>() takes a SourceLocation parameter which with a default value of SourceLocation::Current(), which at least gives us the file name and line number for the error message. Bug: v8:6949, v8:10933 Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#70264}
-
- 25 Sep, 2020 4 commits
-
-
Bill Budge authored
Bug: v8:10933 Change-Id: I4db540cf47ce5cfa25757d776a2bf988ce3ed554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432072Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#70147}
-
Gus Caplan authored
This fixes the logic in the desugaring of destructuring assignments. In particular, a spread element would not check if previous `next` results had already been done, and would always call `next()` again. Change-Id: I1bd384678722e6cf51c5777fc3b0dd965360291a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2430488 Commit-Queue: Gus Caplan <snek@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70144}
-
Victor Gomes authored
- InterpretedFrames are just StandardFrames with 2 extra values. - BuiltinExitFrames are ExitFrames with 4 extra expected arguments. Change-Id: I2c4e4a24185bfa0f23ff63616c8ef66780506796 Bug: v8:10933 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429948Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70140}
-
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}
-
- 08 Sep, 2020 3 commits
-
-
Leszek Swirski authored
Change FeedbackVector into a Torque-generated class, simplifying its C++ implementation. As a drive-by, also get rid of the lower-cased, integer-indexed slot accessors, and replace the calls that needed this integer index with FeedbackSlot (potentially with a new WithOffset adjustment for extra data slots). Change-Id: Ie4f7e99b462ef95419edab46b4ac7ceecae9a05f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398638 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69749}
-
Santiago Aboy Solanes authored
Original CL by neis@: http://crrev.com/c/v8/v8/+/2362693/1 Bug: v8:7790, v8:10853 Fixed: v8:10853 Change-Id: If0bd45e9dfb00f8ef1a358953dab1f5e1c9ae29e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387960Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69742}
-
Marja Hölttä authored
Bug: v8:9237 Change-Id: I06d7e74ba0360334e6fa65c19f24548e220e4c69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349297 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69735}
-
- 02 Sep, 2020 1 commit
-
-
HyeockJinKim authored
During spread operation, after VisitForAccumulatorValue, set the position of the current expression again Bug: chromium:929844 Change-Id: I6e9ca87587789f9cb21e939d4405414c8170b232 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379531 Commit-Queue: HyeockJin Kim <kherootz@gmail.com> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69677}
-
- 28 Aug, 2020 1 commit
-
-
Marja Hölttä authored
This is the first step in a series of CLs. The goal is to make super property access faster. Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit?usp=sharing This CL: - Add bytecode LdaNamedPropertyFromSuper - IGNITION_HANDLER just calls Runtime::LoadFromSuper - JSGenericLowering::LowerJSLoadNamedFromSuper just replaces the node with a runtime call to Runtime::LoadFromSuper Bug: v8:9237 Change-Id: Id28e935294c5068dd6c54e6b860a77d61517fff5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327912 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69604}
-
- 21 Aug, 2020 1 commit
-
-
Ross McIlroy authored
Also removes bmeurer@ from interpreter/OWNERS. BUG=v8:10806 Change-Id: I97cb77350271f773600e92d4ce787080388eb14c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2369179 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69522}
-
- 14 Aug, 2020 1 commit
-
-
Leszek Swirski authored
This patch introduces a new LocalIsolate and LocalFactory, which use LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows us to remove those classes, as well as the related OffThreadSpace, OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle. OffThreadLogger becomes LocalLogger. LocalHeap behaves more like Heap than OffThreadHeap did, so this allows us to additionally remove the concept of "Finish" and "Publish" that the OffThreadIsolate had, and allows us to internalize strings directly with the newly-concurrent string table (where the implementation can now move to FactoryBase). This patch also removes the off-thread support from the deserializer entirely, as well as removing the LocalIsolateWrapper which allowed run-time distinction between Isolate and OffThreadIsolate. LocalHeap doesn't support the reservation model used by the deserializer, and we will likely move the deserializer to use LocalIsolate unconditionally once we figure out the details of how to do this. Bug: chromium:1011762 Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990 Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69397}
-
- 06 Aug, 2020 1 commit
-
-
Bill Budge authored
This is a reland of ce249dbb As it's unchanged, TBR=leszeks@chromium.org,tebbi@chromium.org Original change's description: > [torque] Port some constructor builtins to Torque. > > - FastNewFunctionContextEval > - FastNewFunctionContextFunction > - CreateEmptyLiteralObject > - CreateRegExpLiteral > - CreateEmptyArrayLiteral > - CreateShallowArrayLiteral > - CreateShallowObjectLiteral > - NumberConstructor > - ObjectConstructor > - GenericLazyDeoptContinuation > > Bug: v8:9891 > > Change-Id: Idd4bf035d8dbeec03b9ef727e1bfb80eab4bc43c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311411 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69082} Bug: v8:9891 Change-Id: I566d4167c02488ef6a9a1c73015af5e2f484a31d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330382 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69281}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
With the new Turbofan variants (NCI and Turboprop), we need a way to distinguish between them both during and after compilation. We initially introduced CompilationTarget to track the variant during compilation, but decided to reuse the code kind as the canonical spot to store this information instead. Why? Because it is an established mechanism, already available in most of the necessary spots (inside the pipeline, on Code objects, in profiling traces). This CL removes CompilationTarget and adds a new NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine various things about a given code kind (e.g.: does this code kind deopt?). As a (very large) drive-by, refactor both Code::Kind and AbstractCode::Kind into a new CodeKind enum class. Bug: v8:8888 Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 29 Jul, 2020 1 commit
-
-
Jakob Gruber authored
This is the first step towards implementing a tier-up mechanism from NCI code to TF. We will follow the existing Ignition-to-Turbofan mechanics, which are, roughly: 1. Track a bytecode interrupt budget. 2. When exhausted, call the runtime profiler, which increments profiler ticks for the top frame's function. 3. When a function should tier up, it is marked as such using the FeedbackVector::optimized_code_weak_or_smi slot / the OptimizationMarker mechanism. 4. The InterpreterEntryTrampoline checks this slot and calls into runtime to compile if needed. 5. The finished code is also placed into this slot, as well as installed on the JSFunction. 6. Again, the IET checks the slot and tail-calls the code object if it exists. This CL implements step 1 for NCI code by inserting the new simplified UpdateInterruptBudget operator at the same spots (and using the same offsets) as Ignition. When the budget is exhausted, we call a runtime function that currently does nothing and will be implemented in the next CL. Bug: v8:8888 Change-Id: I98c0f8d96f32d515218dc2a76f961d44fe281c86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312778 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69124}
-
- 27 Jul, 2020 2 commits
-
-
Shu-yu Guo authored
This reverts commit ce249dbb. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/32375 Original change's description: > [torque] Port some constructor builtins to Torque. > > - FastNewFunctionContextEval > - FastNewFunctionContextFunction > - CreateEmptyLiteralObject > - CreateRegExpLiteral > - CreateEmptyArrayLiteral > - CreateShallowArrayLiteral > - CreateShallowObjectLiteral > - NumberConstructor > - ObjectConstructor > - GenericLazyDeoptContinuation > > Bug: v8:9891 > > Change-Id: Idd4bf035d8dbeec03b9ef727e1bfb80eab4bc43c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311411 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69082} TBR=bbudge@chromium.org,jgruber@chromium.org,leszeks@chromium.org,tebbi@chromium.org Change-Id: I76272a4d439ef95213fdfb659bdbcb71e16daec6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9891 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2321111Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#69084}
-
Bill Budge authored
- FastNewFunctionContextEval - FastNewFunctionContextFunction - CreateEmptyLiteralObject - CreateRegExpLiteral - CreateEmptyArrayLiteral - CreateShallowArrayLiteral - CreateShallowObjectLiteral - NumberConstructor - ObjectConstructor - GenericLazyDeoptContinuation Bug: v8:9891 Change-Id: Idd4bf035d8dbeec03b9ef727e1bfb80eab4bc43c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311411 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69082}
-
- 24 Jul, 2020 2 commits
-
-
Igor Sheludko authored
... that controls whether the TF graph zones should support compression. Bug: v8:9923 Change-Id: Ifbe237b75e9c92e62eb32b69d6b3b1a818269b83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308347 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69036}
-
Leszek Swirski authored
Allow "iterative" finalization when off-thread finalization is enabled, meaning that each compiled function is finalized immediately after compilation, rather than all functions being first compiled and then finalized. This is what we do on the main thread, and it reduces peak Zone memory usage by being able to discard empty compilation Zones earlier. One necessary functionality for this was being able to defer the finalization of asm.js functions until the main thread pause, since they can't be finalized off-thread -- previously we would just bail out of doing the off-thread finalization if any inner function was asm.js. Bug: chromium:1011762 Change-Id: I21ff69d62eaa93b5ff908624b7115601e36f70f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282536Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69032}
-
- 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}
-
- 15 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... this will avoid the need to pass AllocationPolicy to every method that can allocate/deallocate and allows to make deallocation method implementation stateful. The latter will also allow implementing accounting of deallocated zone memory. Adding one more field is generally fine because usually these hashmap objects are allocated on the stack or inside other rarely-allocated long-lived objects. The only exception is Scope class. The Scope objects are created very often during parsing and each of them has a VariableMap field. The Scope object size issue will be addressed in a follow-up CL. Bug: v8:10572 Change-Id: I63fbd41246cf2e568c8ba80c213d3e9caffc2c87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284992Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68877}
-
- 13 Jul, 2020 1 commit
-
-
Igor Sheludko authored
Also make ScopedList class Zone-agnostic and move it to src/utils. Bug: v8:10506 Change-Id: Ibf0869566caa767809bdf95cb03c01e599613938 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292234Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68825}
-
- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: Ic7d893b8d6772bd923c37c3d1e7cff5cc6667192 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288868 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68786}
-
- 08 Jul, 2020 1 commit
-
-
Victor Gomes authored
The second argument of FromParameterIndex should be the parameter count, including the receiver. Previously it worked by chance, because the code was trying to access the receiver but did not include it in the parameter count, accessing the first argument. This does not work anymore when the arguments are reversed (V8_REVERSE_JSARGS). Change-Id: I8ca9054a99d074c130f9a9b444e7b8a379840991 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282531Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68742}
-
- 07 Jul, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: I00c74df771ce719c318045f57b075ac2cb5df5fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282593Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68707}
-
- 17 Jun, 2020 1 commit
-
-
Jakob Gruber authored
... for nci code, in which several phases of the compiler are not active: LowerJSCreateCatchContext LowerJSCreateEmptyLiteralObject LowerJSCreateIterResultObject LowerJSCreateWithContext LowerJSGetIterator LowerJSGetTemplateObject With this change, the nci variant passes the test suite. Tests relying on turbofan-specific behavior (e.g. deopts) are skipped. Bug: v8:8888 Change-Id: I709178241e9b25e7480a39b4fb64bdcf576483be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245604 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68381}
-
- 03 Jun, 2020 1 commit
-
-
Jakob Gruber authored
This brings %DebugPrint(string) closer to %DebugPrint(object) by also including the pointer, object kind, and RO/old space. Especially the pointer can be useful while debugging. One could consider going even further end printing full details of the string object, e.g. first and second pointers for cons strings. Before: $ out/debug/d8 --allow-natives-syntax -e '%DebugPrint("abc");' DebugPrint: #abc 0x263f080402cd: [Map] in ReadOnlySpace [...] After: $ out/debug/d8 --allow-natives-syntax -e '%DebugPrint("abc");' DebugPrint: 0xa830824ffe1: [String] in OldSpace: #abc 0xa83080402cd: [Map] in ReadOnlySpace [...] Drive-by: Document string printing functions. Drive-by: Use PrintUC16 in spots that don't want a full debug print. Bug: v8:10581 Change-Id: Ided59047b9c3edc1830ce7721376dddfd24fad1d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228509Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68136}
-
- 02 Jun, 2020 1 commit
-
-
Clemens Backes authored
The SourcePositionTableBuilder unconditionally allocates heap memory for every Liftoff compilation. This shows up with 1-2% of compilation time in profiles. Hence move the vector contained in the SourcePositionTableBuilder into the compilation zone. Such a zone already exists for both Liftoff and TurboFan, so we can easily save allocations this way. R=thibaudm@chromium.org Bug: v8:10576 Change-Id: Ia83d05cc8c36c775ebff6ec2064e9c3f8cc4d384 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2224221 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68112}
-
- 27 May, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Also remove a version that was only used once. Bug: v8:9708, v8:6949 Change-Id: Ifd65af3866a3740d8da6d4501445b25a48d7219a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212264Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68006}
-
- 25 May, 2020 2 commits
-
-
Shu-yu Guo authored
Bug: v8:10552 Change-Id: I1160ff0f9d2c91bb3c2ad3e0d5e1f36953538420 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211402Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67959}
-
Jakob Gruber authored
This CL adds the new _WithFeedback variant of unary, binary, and compare operation builtins. Existing logic to do these operations is refactored s.t. it can be used by both ignition bytecode handlers and the new builtins. Note that the new builtins are not yet used. Follow-up CLs will hook them into generic lowering. Bug: v8:8888 Change-Id: Id77dbe74bdf3b3806b2aefdf1abe52c3d165a3a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208862 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67956}
-
- 12 May, 2020 1 commit
-
-
Jakob Gruber authored
Previously implemented directly in InterpreterAssembler::Construct, this will soon also be needed to implement a Construct_WithFeedback builtin. Bug: v8:8888 Change-Id: I01a00914c6554a5b83f414a93d85a15ec02df662 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193717 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67753}
-
- 11 May, 2020 1 commit
-
-
Jakob Gruber authored
Collecting feedback for {Call,InstanceOf,Construct} is similar but distressingly different. In preparation for adding a CollectConstructFeedback helper, this CL ports {Call,InstanceOf} feedback collection to Torque. Bug: v8:8888 Change-Id: Iaacc137ef46a77a4fe2857ec41c5cc30614dfdf0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187497Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67703}
-
- 07 May, 2020 1 commit
-
-
Shu-yu Guo authored
Normative change in ecma262 [1]. Errors thrown by GetMethod(iterator, "return") are suppressed in favor of the original exception. [1] https://github.com/tc39/ecma262/pull/1408 Bug: v8:10397 Change-Id: I0dea8bd677c557cced7103c846416bd81f06f482 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183400 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67662}
-
- 06 May, 2020 1 commit
-
-
Leszek Swirski authored
This patch unfies the finalization logic between the various unoptimized compilation paths in compiler.cc, taking the various post-processings and fixups needed for off-thread finalization and performing them in the same order for the other finalizations. It also unifies the general compilation path between streaming script compilation, main-thread script compilation, and main-thread lazy compilation, making the main-thread paths both use an iterative execution and finalization, and making all three use the same job helper methods and overall finalization helper. Bug: chromium:1011762 Change-Id: Ibe56f6d2f75a2deffbe9e0b600ded8a02293b722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172790 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67609}
-