- 09 Mar, 2020 8 commits
-
-
Georg Neis authored
Bug: chromium:1051017 Change-Id: Id300c6d5f88b762e465383ac78ed037d3bc958d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089938 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66627}
-
Santiago Aboy Solanes authored
This CL merges nested loops that share the same header offset with its parent loop, by not emitting JumpLoop bytecode for these inner loops. Instead, we generate a Jump to its parent's JumpToHeader (which in turn can be a JumpLoop or another Jump to its parent's JumpToHeader). Originally, every loop had a unique first Bytecode to jump to. Since IterationBody StackChecks are going to become implicit this will no longer be the case. As a note, this CL just sets the foundation that the follow-up CLs will build on top of. Since we have explicit StackChecks, and they are at the beginning of loops we do not have nested loops as of now. Bug: v8:10149, v8:9960 Change-Id: I6daee4d2c6d6216f022228c87c4aa74e163997b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062390 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66626}
-
Santiago Aboy Solanes authored
Change-Id: Iae85e97cd59f3270959e506f43dae22e6a331217 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078580Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66625}
-
Nico Hartmann authored
Bug: v8:9612 TBR=sathya@chromium.org, syg@chromium.org Change-Id: I6101d30e5af3e677c35deba202e22dfe4aa36869 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093498Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66624}
-
Jakob Kummerow authored
Considering that the security benefit is unclear at this point, the performance and binary size costs are not justified. This CL includes reverts of earlier partial disablings: 173a2bd8 af7bf14f 85f72be3 Bug: chromium:977230, chromium:1055312, chromium:1055317 Change-Id: I173b61656a542687c4619fa374a0b2ee22c85ef7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091474Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Hablich <hablich@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66623}
-
Dan Elphick authored
String::NewFromLiteral is a templated function that takes a char[N] argument that can be used as an alternative to String::NewFromUtf8 and returns a Local<String> rather than a MaybeLocal<String> reducing the number of ToLocalChecked() or other checks. Since the string length is known at compile time, it can statically assert that the length is less than String::kMaxLength, which means that it can never fail at runtime. This also converts all found uses of NewFromUtf8 taking a string literal or a variable initialized from a string literal to use the new API. In some cases the types of stored string literals are changed from const char* to const char[] to ensure the size is retained. This API does introduce a small difference compared to NewFromUtf8. For a case like "abc\0def", NewFromUtf8 (using length -1 to infer length) would treat this as a 3 character string, whereas the new API will treat it as a 7 character string. As a drive-by fix, this also fixes all redundant uses of v8::NewStringType::kNormal when passed to any of the String::New* functions. Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66622}
-
Tobias Tebbi authored
In the process: * Augment C++-generated Torque classes with SizeFor methods to calculate size of instances. * Add a new "@generateBodyDescriptor" annotation that causes Torque to generate C++ BodyDescriptors code that can be used to visit objects compatible with existing V8 mechanisms, e.g. GC * Fully automate C++ macro machinery so that adding non-extern Torque class doesn't require any C++ changes, including ensuring generation of instance types and proper boilerplate for validators and printers. * Make handling of @export a true annotation, allowing the modifier to be used on class declarations. * Add functionality such that classes with the @export annotation are available to be used from C++. Field accessors for exported classes are public and factory methods are generated to create instances of the objects from C++. * Change the Torque compiler such that Non-exported classes implicitly have the @generateBodyDescriptor annotation added and causes both verifiers and printers to be generated. * Switch non-extern Torque classes from using existing Struct-based machinery to being first-class classes that support more existing Torque class features. Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Nico Hartmann authored
Bug: v8:9612 TBR=gsathya@chromium.org, syg@chromium.org Change-Id: I95b70f0c443904acd7fe1d05077acba28713b2b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093494 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
- 06 Mar, 2020 18 commits
-
-
Zhao Jiazhong authored
Port fd735e84 https://crrev.com/c/2067631 Change-Id: I720c4e218ea7a6088c61c2411c7c74e636f0772a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089228Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66619}
-
Ng Zhi An authored
Bug: v8:10233 Change-Id: I8bb564e595d5c2b093adea0b9dde9c1c86dcee70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084318Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66618}
-
Nate Chapin authored
This state can be set on the NativeContext by the embedder. When a PromiseReaction/PromiseReactionJobTask is constructed, store this contextual state if present, and restore it while the reaction job is running. Change-Id: I141cdbd9e36ea83ce4a6bf08440ae7eaa54523df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2005849Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/master@{#66617}
-
Ng Zhi An authored
Implement f64x2, i64x2, i8x16 splats on arm and arm64. Bug: v8:9909 Change-Id: I41f635ae5c6f025ece7f6445a58fbad1ad678fbd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087694Reviewed-by:
-
Zhao Jiazhong authored
Port 820faa6e https://crrev.com/c/2056468 Original Commit Message: The arm/arm64 simulators debugger has a command "mem" that prints the content of the memory. It also prints a short summary for JS objects (SMI, Array, JSFunction, ...). That is very handy, but when trying to print incomplete initialized memory, it could raise an exception. It is useful to have a command that prints the content of the memory for non-initialized or bogus values without the risk of raising an exception. This CL adds the command "dump". Change-Id: If8c96d7bac4a484c2a4fee9d192a29ea2696580a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089224Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66615}
-
Milad Farazmand authored
Port fd735e84 R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I8a46492241be9686da2220cb99162c9610962b5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091212Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66614}
-
Andreas Haas authored
Prefixed opcodes do not get written correctly in code comments in Liftoff. The reason is that only one byte is interpreted as the opcode, but prefixed opcodes take two bytes. This CL loads the second byte if necessary. The change could be done in function-body-decoder-impl.h, but that could lead to performance regressions: it is a hot code path, and the change here is just for debugging. R=clemensb@chromium.org Bug: v8:10155 Change-Id: I2282c068c81b5b1e2e2ed9757f4e77687d1d4ede Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091467Reviewed-by:
-
Pierre Langlois authored
Comments on this reservation indicate it may hold either only code pages or code and data pages if pointer compression is enabled. But in fact it only holds the reservation for code pages. Change-Id: Ic007fcadf881153b69dce51db561777cc52685bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091465Reviewed-by:
-
Clemens Backes authored
The test started failing (sometimes flaking) on an unrelated CL. R=gsathya@chromium.org Bug: v8:10307 Change-Id: If198c2cf518f7a36e54614307462272774d9e48e No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091466Reviewed-by:
-
Andreas Haas authored
This CL fixes a special case where a WasmExportedFunction is passed to the WebAssembly.Function constructor. This is a case that was not yet implemented in V8, and which is also not specified in the proposal yet. With this CL we do a signature check of the provided function. If it matches, the function itself is returned. Otherwise a TypeError is thrown. I filed an issue: https://github.com/WebAssembly/js-types/issues/13 R=jkummerow@chromium.org Bug: chromium:1057534 Change-Id: Ib09d1ba18abaa6a8dd451aa747fd26c03d927413 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084813 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66610}
-
Zhao Jiazhong authored
Port 7ad6b04e https://crrev.com/c/2080362 Change-Id: Iac305bf76c5a602bd238310fed0828e5ea95cd0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084323Reviewed-by:
-
Vitaly Buka authored
Bug: chromium:1055312, chromium:977230 Change-Id: I2ee8776b5118b07e414a1e88e43cc42ab82ecc64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090982Reviewed-by:
-
Andreas Haas authored
All other simple C functions take a pointer to a stack slot which contains the actual parameters, whereas the memory_copy_wrapper takes three parameters. This makes the code generation from Liftoff more difficult. This CL changes the signature of memory_copy_wrapper to match the signature of other simple C functions. As MemoryCopy and MemoryInit are already implemented with C calls, this change should not make a big difference in terms of performance. Simpler and smaller Liftoff code may have more effect on performance. If this assumption turns out wrong, we can change it in the future. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I39e0ea00fcb22b4e84e612fe58eb4642856b72c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078576 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
This adds two new histograms: - V8.MeasureMemoryDelayMilliseconds measures how long it takes to serve a memory measurement request - V8.GCFinalizeMCMeasureMemory is a variant of the existing GC pause histogram that used when GC runs in memory measurement mode. Additionally this CL lowers the maximum measurement delay to 10 seconds. Bug: chromium:1049093 Change-Id: I97cbf443da514a69d6cf8c1d74d2757098e60acd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089937Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66606}
-
Milad Farazmand authored
Change-Id: Id5d6d1b2b6c06a2c4d1712bfa281bce18fb1320a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090533Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/fa4450f..e393474 Rolling v8/third_party/aemu-linux-x64: hvClQbzFhJApEEpHpfc8UqpDdzLK0eabIbmpPlfODp8C..7YlCgase5GlIanqHn-nZClSlZ5kQETJyVUYRF7Jjy6UC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f6edc90..b3bfbaa Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fe6f752..ee8be8a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/d548cda..101bca1 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5ab721e9e72c0f7bae5790dbde73478c6ba78d61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089726Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66604}
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I8dc5d0143d90ecad6766c686af2d3f0f8ea89c16 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2067631Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10180 Change-Id: If8dd729739854ee0bc08bf71100f48de6a0437b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084321Reviewed-by:
-
- 05 Mar, 2020 13 commits
-
-
Zhao Jiazhong authored
Port 34f9bcdb https://crrev.com/c/2067845 Original Commit Message: Implements i8x16.abs, i16x8.abs, and i32x4.abs. Change-Id: I95800caa298860326e3deadea2fce71640ae0227 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2086532Reviewed-by:
-
Andrey Kosyakov authored
This retrieves script name directly from StackFrameBase, bypassing building of StackFrameInfo if one hasn't already been initialized, thus avoiding computation of expensive properties that are not required. Bug: chromium:1057211 Change-Id: I91eaecdbaee6f5834a02d70e2df872e82998ab83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080663 Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#66600}
-
Vitaly Buka authored
Change-Id: Ie7ccf955ea629eec612a80e264ac71050cbc4cff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090531 Commit-Queue: Vitaly Buka <vitalybuka@chromium.org> Auto-Submit: Vitaly Buka <vitalybuka@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#66599}
-
Clemens Backes authored
This is a reland of 79398ab0 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934Reviewed-by:
-
Clemens Backes authored
This reverts commit 79398ab0. Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org Change-Id: Id80aa82cfce8942879031032b322ee66855b5600 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10254 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933Reviewed-by:
-
Clemens Backes authored
Also, save dynamic allocations (plus their memory overhead). This is realized by storing the relocation information, source position table, and protected instruction information together in one "metadata" byte array. For each of the three components, we just store their size, such that the accessors can return the respecitive {Vector} views as before. This makes each WasmCode object 24 bytes smaller on 64-bit architectures. It also saves a few more bytes per code object because less padding is needed for the individual allocations, and each dynamic allocation comes with some constant memory overhead. Since the protected instructions will just be stored in a byte array now, some APIs are refactored to just return that byte array directly (instead of an array of {ProtectedInstructionData}). This also simplifies serialization and deserialization, and will allow for switching to a more compact representation in the future. Drive-by: Add some more checks to {Vector::cast} to protect against undefined behaviour. R=ahaas@chromium.org Bug: v8:10254 Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545Reviewed-by:Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Victor Gomes authored
- Create a PushArray to simplify code. - Adapt all the sites in builtins-x64. Bug: v8:10201 Change-Id: I828f4d2e43373a4fe6380346c5628a345720fe38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083028Reviewed-by:
-
Zhao Jiazhong authored
Port 9245e3b4 https://crrev.com/c/2049247 Change-Id: Ic2df706a4d5f7df8a2cdb4f53c4679cf96f0b8b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2086535Reviewed-by:
-
Victor Gomes authored
Bug: v8:10201 Change-Id: I2271602b2da6fd06038ddfab16090d7faac592ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074218 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This fixes a non-determinism issue caused by the cache being full. Depending on the non-deterministic value of the handles in HeapConstant nodes, different cache entries would be overwritten in this case. The old implementation of NodeCache had a fixed limit, overwriting entries when the cache is full. This behavior didn't really make sense, but the hand-written hash map implementation couldn't handle arbitrary numbers of hash collisions, so removing the limit wasn't an option either. Thus this CL just replaces the custom hash map with a normal std::unordered_map, that is, a ZoneUnorderedMap. Bug: chromium:1046815 Change-Id: I95269f2b1068eb9dfe3ee2ab5cca1cb460bc8fa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087405Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
-
Dan Elphick authored
Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by taking advantage of SparseInputMask data structure to more quickly handle empty inputs and insert all the OptimizedOut entries in one go. The number of empty inputs is now determined using CountTrailingZeros rather than iterating over them one at a time. Gives a 9% improvement to SelectInstructions runtime call stat for Octane in turboprop. Bug: v8:10051 Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Georg Neis authored
Change-Id: I6094bc17e8a482f166bdb53e5d2dabe9a1299c9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087409 Commit-Queue: Dan Elphick <delphick@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#66590}
-
Vitaly Buka authored
It's probably possible to limit this to a few variables. However, at the moment I am able to create a patch with tens of V8_STACK_UNINITIALIZED. It seems tiny changes in functions sizes causes significant changes in optimizer behavior. For now I'd like just to restore the perf. Bug: chromium:1055312, chromium:977230 Change-Id: I48efc3c872a4039b253011b70baf40763e181a20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087452 Commit-Queue: Vitaly Buka <vitalybuka@chromium.org> Reviewed-by:
-
- 04 Mar, 2020 1 commit
-
-
Ng Zhi An authored
Bug: v8:9561 Change-Id: I5fbf69aaacccfe588f95edf1208176e3a7de62bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071397Reviewed-by:
-
