- 20 Jul, 2022 1 commit
-
-
ishell@chromium.org authored
... in favour of Builtins::name(). Bug: v8:11880 Change-Id: I1e06314aec71ea367cd8096316e8fb9aceb63feb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776686 Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81854}
-
- 08 Jul, 2022 1 commit
-
-
Manos Koukoutos authored
Mostly src/codegen, src/compiler, src/interpreter, src/libplatform. Drive-by: Remove some unreachable code. Bug: v8:13006 Change-Id: I1a9467f7e42531c545f660d35416c388e8ef9d3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749193 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81613}
-
- 16 Dec, 2021 2 commits
-
-
Igor Sheludko authored
This CL * removes Builtins::codet() and Builtins::codet_handle() returning builtins as CodeT objects in favor of code() and code_handle(), * removes BUILTIN_CODET macro in favor of BUILTIN_CODE, * removes CodeDataContainer table. Bug: v8:11880 Change-Id: Ic868549030744b0ff3ea5d5edbfcacf77c6de96d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344650Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78399}
-
Igor Sheludko authored
... in order to avoid Code <-> CodeT conversions in builtins. This CL changes the meaning of RelocInfo::CODE_TARGET which now expects CodeT objects as a code target. In order to reduce code churn this CL makes BUILTIN_CODE and friends return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and friends will be removed. Bug: v8:11880 Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483Reviewed-by:
Patrick Thier <pthier@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78393}
-
- 10 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Rather than requiring the user of a LocalIsolate to pass in a RuntimeCallStats from a WorkerThreadRuntimeCallStatsScope, create the scope in the LocalIsolate directly and use its RuntimeCallStats in the LocalIsolate constructor. We can't do this for the main thread LocalIsolate, since WorkerThreadRuntimeCallStatsScope doesn't work on the main thread, so there we use the main-thread RuntimeCallStats instead. This flushes out some issues of background-thread LocalIsolates being used on the main thread, so fix those too, as well as RCS scopes using background counters for operations that could happen on the main thread. Change-Id: I21a53be0771f47a03ccdb27d24c2b9d25d8b2d1c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318664Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78334}
-
- 15 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Posting compile tasks from the parser has several issues: 1. We don't know how many functions there will be total, so we can't yet allocate shared_function_infos array on the Script 2. Without this array, inner function compiles can't look up their own inner functions during bytecode finalization, so we can't run that finalization before script parse completes 3. Scope analysis can't have run yet, so we can only post top-level function tasks and if we allocate SharedFunctionInfos early they are forced into a bit of a limbo state without an outer ScopeInfo. Instead, we can post compile tasks during bytecode generation. Then, the script parse is guaranteed to have completed, so we'll have a shared_function_infos array and we will have allocated ScopeInfos already. This also opens the door for posting tasks for compiling more inner functions than just top-level, as well as generating better code for functions/methods that reference same-script top-level let/const/class. Bug: chromium:1267680 Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77894}
-
- 25 Aug, 2021 1 commit
-
-
Leszek Swirski authored
Make the GetDispatchCountersObject function return an internal Handle rather than an API Local. Also, port its implementation to use internal methods rather than API methods. Change-Id: I191e0483263009c835c801462822e4fc7e78680e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3110198 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#76485}
-
- 18 Jun, 2021 1 commit
-
-
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
- 14 Jun, 2021 1 commit
-
-
Camillo Bruni authored
- Convert Builtin to enum class - Change int-based builtin_index methods to use Builtin - Change Builtins::builtin to Builtins::code Change-Id: Id9e3bb83da97e8894ca7ca78e1e852da60675619 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949104 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75127}
-
- 09 Jun, 2021 1 commit
-
-
Dan Elphick authored
By moving this out of counters.h, counters.h no longer needs to depend on isolate.h. Change-Id: Ic5272e3b3a729c0a438124dc5cdc1835817f3341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949098 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75055}
-
- 07 Jun, 2021 2 commits
-
-
Camillo Bruni authored
- Add new Builtin enum - Move Builtins::Name:kXXX to Builtin::kXXX - Update existing code Follow CLs will unify the mix of using int builtin-ids and Builtins::Name to only use the new Builtin enum and changing it to an enum class. Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74995}
-
Seth Brenith authored
The flag --trace-ignition-dispatches has been broken for a long time, since it was not designed to work with bytecode handlers that are generated ahead of time by mksnapshot. This splits the existing --trace-ignition-dispatches logic into two separate parts: 1. A gn argument which instructs mksnapshot to include dispatch counting in the bytecode handlers, and ensures that the Interpreter allocates the array of counters, and 2. A runtime flag which enables the ignition-statistics extension which implements the JS-accessible function getIgnitionDispatchCounters(). Change-Id: I89323425697f5641451f67b9ddcc0303b8ca209f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2937564Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74992}
-
- 26 Apr, 2021 1 commit
-
-
Leszek Swirski authored
It's unfortunate that there is both a LocalIsolate template parameter, and an actual LocalIsolate class. Clean this up by renaming the template parameters to IsolateT Change-Id: Iecefc3eca5aeb7bbd21e78818b90f9e75cdff10f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846880 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74173}
-
- 12 Apr, 2021 1 commit
-
-
Camillo Bruni authored
Make runtime-call-stats a compile-time flag. Disabling RCS saves roughly 1MB binary size on 64bit systems and yields minor performance improvements. Bug: v8:11299 Change-Id: Ia1db75e330a665db5251b685c164b96857e38d2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2799766Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#73910}
-
- 31 Mar, 2021 1 commit
-
-
Dominik Inführ authored
MaybePrintAst needs to be run before parking the thread. It allows handle dereferences internally but that doesn't work when thread is parked. Bug: chromium:1193728 Change-Id: I0adbf6f236be8d442fd8be4d4d6e4931fcff4db6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794432Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#73736}
-
- 29 Mar, 2021 1 commit
-
-
Dominik Inführ authored
It could happen (e.g. with --stress-background-compile) that the main thread blocks for a background thread but the background thread requests a GC from the main thread. This would result in a deadlock. Avoid this by parking the main thread for potentially blocking operations and allow allocations while the main thread is parked. This CL introduces new states for the main thread: CollectionRequested and ParkedCollectionRequested. These states will force Safepoint(), Park() and Unpark() on the main thread into slow paths. The slow path can then perform a GC on the main thread - right before parking or after the main thread got unparked. Bug: v8:10315 Change-Id: If7ef31622d27320613139a0b7f79086fe3200f99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731528Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#73707}
-
- 17 Feb, 2021 1 commit
-
-
Seth Brenith authored
This is a reland of cf93071c Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
-
- 16 Feb, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit cf93071c. Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72777}
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit This change adds 16 new interpreter opcodes, kStar0 through kStar15, so that we can use a single byte to represent the common operation of storing to a low-numbered register. This generally reduces the quantity of bytecode generated on web sites by 8-9%. In order to not degrade speed, a couple of other changes are required: The existing lookahead logic to check for Star after certain other bytecode handlers is updated to check for these new short Star codes instead. Furthermore, that lookahead logic is updated to contain its own copy of the dispatch jump rather than merging control flow with the lookahead-failed case, to improve branch prediction. A bunch of constants use bytecode size in bytes as a proxy for the size or complexity of a function, and are adjusted downward proportionally to the decrease in generated bytecode size. Other small drive-by fix: update generate-bytecode-expectations to emit \n instead of \r\n on Windows. Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72773}
-
- 10 Feb, 2021 1 commit
-
-
Dominik Inführ authored
TimeToSafepoint is the time needed for all background threads to enter a safepoint after the GC was started on the main thread. This CL improves that metric during concurrent compilation to bytecode by doing: 1) Park the LocalIsolate during InterpreterCompilationJob::ExecuteJobImpl. There are no concurrent heap accesses happening while generating bytecode for now. So instead of manually placing Safepoint() invocations in the code, simply park the local isolate. 2) Destroy the LocalIsolate before the ReleaseParser operation. I've seen this take around 2ms, which regressed TimeToSafepoint a lot. 3) Add explicit safepoints to concurrent allocations. This covers the rest of the code and from what I've seen so far this is good enough to keep TimeToSafepoint around a few microseconds. I've still seen TimeToSafepoint events with 20-80 microseconds but those were quite rare and always seemed to be related to Turbofan. AsLocalIsolate() is necessary in generic code to convert both Isolate and LocalIsolate to LocalIsolate. Bug: v8:10315 Change-Id: Idaf9f04ffdf850d0ab0081ec372cc384a9fe7ef9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2663159Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#72618}
-
- 10 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I181af917c141fb327213ae6303057f1bb87f4ac4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2524418Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71064}
-
- 28 Oct, 2020 1 commit
-
-
Dan Elphick authored
This replaces kBytecodeToBuiltinsMapping (an array with currently 549 32-bit integers = 2196 bytes) with kWideBytecodeToBuiltinsMapping which is an array of uint8_t with only 183 values. The new array contains just the mappings from wide handlers to builtins but only once since the mapping is the same for extra wide handlers. (No mapping array is required for normal handlers since they map 1:1). This reduces d8's binary size by 2008 bytes on x64. As a result Interpreter::GetBytecodeHandler will be slightly slower than before, but its only use in non-test code is in Runtime_DebugBreakOnBytecode which does not need to be fast. Bug: v8:11066 Change-Id: Iafc28fba2d1b62c1d49ceabe731d8b52a82dd2fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502291 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70836}
-
- 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}
-
- 08 Sep, 2020 1 commit
-
-
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}
-
- 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}
-
- 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}
-
- 24 Jul, 2020 1 commit
-
-
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}
-
- 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}
-
- 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}
-
- 24 Apr, 2020 1 commit
-
-
Leszek Swirski authored
asm-to-wasm doesn't support off-thread finalization, so disable it if an asm compilation job is successfully executed. Note that in the future, we could instead have a hybrid off-thread and main-thread finalization for mixed JS and asm.js scripts, but for now that's probably unncecessary. Bug: chromium:1011762 Change-Id: I52c8f31fa13790e03ccf3196dbef471bca387bc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110017 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67364}
-
- 22 Apr, 2020 1 commit
-
-
Leszek Swirski authored
This is a reland of e1b93a4f which was a reland of 313d4844 which was a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Give up on using C++ bitfields, go back to having base::BitField and getters/setters. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org Bug: v8:10314 Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67309}
-
- 21 Apr, 2020 4 commits
-
-
Leszek Swirski authored
This reverts commit e1b93a4f. Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274 Original change's description: > Reland^4 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of 313d4844 > which was a reland of 0a59e0cb > which was a reland of 146f5375 > which was a reland of d91679bf > > Manually zero out flags with memset, since GCC appears not to initialize > the bitfield values to zero even with a default constructor. > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org > > Bug: v8:10314 > Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67271} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67275}
-
Leszek Swirski authored
This is a reland of 313d4844 which was a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Manually zero out flags with memset, since GCC appears not to initialize the bitfield values to zero even with a default constructor. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org Bug: v8:10314 Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67271}
-
Sathya Gunasekaran authored
This reverts commit 313d4844. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6354 Original change's description: > Reland^3 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of 0a59e0cb > which was a reland of 146f5375 > which was a reland of d91679bf > > Initializes the BackgroundCompileTasks's language_mode in the > constructor (previously only initialized after successful parse) in case > the parse failed. We still need to reset it after parse in case the > language mode changed (because we encountered "use strict"). > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org > > Bug: v8:10314 > Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67265} TBR=leszeks@chromium.org Change-Id: I90ac035caa76d4c4baf5ce207247d1ce5169fb2f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157370Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#67266}
-
Leszek Swirski authored
This is a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Initializes the BackgroundCompileTasks's language_mode in the constructor (previously only initialized after successful parse) in case the parse failed. We still need to reset it after parse in case the language mode changed (because we encountered "use strict"). Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org Bug: v8:10314 Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67265}
-
- 20 Apr, 2020 4 commits
-
-
Francis McCabe authored
This reverts commit 0a59e0cb. Reason for revert: Still causing UBSAN issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729 Original change's description: > Reland^2 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of d91679bf > which was a reland of d91679bf > > Fixes missing initialization of ParserBase::allow_eval_cache_ > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org > > Bug: v8:10314 > Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67245} TBR=rmcilroy@chromium.org,leszeks@chromium.org Change-Id: I1c5f58cc5608217a149b04aa6f50bb3d7606c26d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157657Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67250}
-
Leszek Swirski authored
This is a reland of d91679bf which was a reland of d91679bf Fixes missing initialization of ParserBase::allow_eval_cache_ Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org Bug: v8:10314 Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67245}
-
Leszek Swirski authored
This reverts commit 146f5375. Reason for revert: UBSan (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10726?) Original change's description: > Reland "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of d91679bf > > This reland adds initializers for the output flags. > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > Bug: v8:10314 > Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67241} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: I204eb9e4d0a5bfaeeefeb6b0f1c82856b57cb175 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157029Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67242}
-
Leszek Swirski authored
This is a reland of d91679bf This reland adds initializers for the output flags. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} Bug: v8:10314 Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67241}
-
- 19 Mar, 2020 1 commit
-
-
Leszek Swirski authored
This reverts commit d91679bf. Reason for revert: Seems to cause UBSan errors Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66783}
-