18393c8c6e
32 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Joyee Cheung
|
0d1ffe30f8 |
[ic] name Set/Define/Store property operations more consistently
For background and reasoning, see https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit This is the first step towards pulling the DefineNamedOwn operation out of StoreIC. Summary of the renamed identifiers: Bytecodes: - StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for normal named property sets like obj.x = 1. - StaNamedOwnProperty -> DefineNamedOwnProperty: calls DefineNamedOwnIC (previously StoreOwnIC), and emitted for initialization of named properties in object literals and named public class fields. - StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted for keyed property sets like obj[x] = 1. - StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for initialization of private class fields and computed public class fields. - StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls DefineKeyedOwnPropertyInLiteral runtime function (previously DefineDataPropertyInLiteral) and emitted for initialization of keyed properties in object literals and static class initializers. (note that previously the StoreDataPropertyInLiteral runtime function name was taken by object spreads and array literal creation instead) - LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty -> GetNamedProperty, LdaNamedPropertyFromSuper -> GetNamedPropertyFromSuper: we drop the Sta prefix for the property store operations since the accumulator use is implicit and to make the wording more natural, for symmetry the Lda prefix for the property load operations is also dropped. opcodes: - (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for named properties, compiled from SetNamedProperty (previously StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty - (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define semantics for initializing named own properties in object literal and public class fields, compiled from DefineNamedOwnProperty (previously StaNamedOwnProperty) and lowers to DefineNamedOwnIC (previously StoreOwnIC) - (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics for keyed properties, only compiled from SetKeyedProperty(previously StaKeyedProperty) and lowers to KeyedStoreIC - (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define semantics for initialization of private class fields and computed public class fields, compiled from DefineKeyedOwnProperty (previously StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously KeyedDefineOwnIC). - (JS)StoreDataPropertyInLiteral -> (JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for initialization of keyed properties in object literals and static class initializers, compiled from DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral) and calls the DefineKeyedOwnPropertyInLiteral runtime function (previously DefineDataPropertyInLiteral). Runtime: - DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: following the bytecode/opcodes change, this is used by DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral) for object and class literal initialization. - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple: it's just a simplified version of DefineDataPropertyInLiteral that does not update feedback or perform function name configuration. This is used by object spread and array literal creation. Since we are renaming DefineDataPropertyInLiteral to DefineKeyedOwnPropertyInLiteral, rename this simplified version with a `_Simple` suffix. We can consider merging it into DefineKeyedOwnPropertyInLiteral in the future. See https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU - Other changes following the bytecode/IR changes IC: - StoreOwn -> DefineNamedOwn: used for initialization of named properties in object literals and named public class fields. - StoreOwnIC -> DefineNamedOwnIC - StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn - StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn - IsStoreOwn() -> IsDefineNamedOwn() - DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and keyed defines so we don't need an extra generic predicate. - StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn - StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn - IsDefineOwn() -> IsDefineKeyedOwn() - IsDefineOwnIC() -> IsDefineKeyedOwnIC() - Removing IsKeyedDefineOwnIC() as its now a duplicate of IsDefineKeyedOwnIC() - KeyedDefineOwnIC -> DefineKeyedOwnIC, KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator: make the ordering of terms more consistent - IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is removed since it's just a duplicate of this. - IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the "keyed" part came from, but it's only used when DefineNamedOwnIC (previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly Interpreter & compiler: - BytecodeArrayBuilder: following bytecode changes - StoreNamedProperty -> SetNamedProperty - StoreNamedOwnProperty -> DefineNamedOwnProperty - StoreKeyedProperty -> SetKeyedProperty - DefineKeyedProperty -> DefineKeyedOwnProperty - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral - FeedbackSlotKind: - kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more consistent - kStoreOwnNamed -> kDefineNamedOwn: following the IC change - kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only used in StoreIC for set semantics - kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used in KeyedStoreIC for set semantics - kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral: following the IC change - BytecodeGraphBuilder - StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the difference between SetNamedProperty and DefineNamedOwnProperty operations. Not changed: - StoreIC and KeyedStoreIC currently contain mixed logic for both Set and Define operations, and the paths are controlled by feedback. The plan is to refactor the hierarchy like this: ``` - StoreIC - DefineNamedOwnIC - SetNamedIC (there could also be a NamedStoreIC if that's helpful) - KeyedStoreIC - SetKeyedIC - DefineKeyedOwnIC - DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC) - StoreInArrayLiteralIC - ... ``` StoreIC and KeyedStoreIC would then contain helpers shared by their subclasses, therefore it still makes sense to keep the word "Store" in their names since they would be generic base classes for both set and define operations. - The Lda and Sta prefixes of bytecodes not involving object properties (e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on property operations, and distinction between Set and Define might be less relevant or nonexistent for bytecodes not involving object properties. We could consider rename some of them in future patches if that's helpful though. Bug: v8:12548 Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79409} |
||
Kim-Anh Tran
|
f74ea020d5 |
[bytecode-generator] Move source code position for classes
Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940} |
||
Seth Brenith
|
7be64db45f |
Reland "[interpreter] Short Star bytecode"
This is a reland of
|
||
Leszek Swirski
|
08a49bbe50 |
Revert "[interpreter] Short Star bytecode"
This reverts commit
|
||
|
Seth Brenith
|
cf93071c91 |
[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} |
||
Marja Hölttä
|
31d2bb8670 |
Reland2 [super] Store home object in Context instead of JSFunction
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422} |
||
|
Marja Hölttä
|
12f8ac4713 |
Revert "Reland [super] Store home object in Context instead of JSFunction"
This reverts commit
|
||
|
Marja Hölttä
|
f6450b97ec |
Reland [super] Store home object in Context instead of JSFunction
1) Computed property keys (esp functions in them) shouldn't be inside the object literal scope. 2) I was using an imprecise "maybe uses super" and storing it to preparse data. This won't fly, since it pollutes sister scopes and leads to confusion wrt whether an object literal needs a home object or not. Made it precise (mostly cancelling changes in the original CL). 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for this_function (which made it used) -> inconsistent scopes between parsing and preparsing. 4) MultipleEntryBlockContextScope was messing up the accumulator Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72169} |
||
Maya Lekova
|
e3dbd69fea |
Revert "[super] Store home object in Context instead of JSFunction"
This reverts commit
|
||
|
Marja Hölttä
|
4d5b878b61 |
[super] Store home object in Context instead of JSFunction
This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72137} |
||
Santiago Aboy Solanes
|
9d3dc6f219 |
[interpreter] Make FunctionEntry StackCheck bytecodes implicit
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206} |
||
Victor Gomes
|
dbbdd0eca2 |
Reland x3 "[runtime] Remove extension slots from context objects"
Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477} |
||
Clemens Backes
|
725e7dd75a |
Revert "Reland "Reland "[runtime] Remove extension slots from context objects"""
This reverts commit |
||
|
Victor Gomes
|
392a1217de |
Reland "Reland "[runtime] Remove extension slots from context objects""
This is a reland of |
||
|
Leszek Swirski
|
08955bb258 |
Revert "Reland "[runtime] Remove extension slots from context objects""
This reverts commit |
||
|
Victor Gomes
|
c48096d442 |
Reland "[runtime] Remove extension slots from context objects"
This is a reland of
|
||
Sathya Gunasekaran
|
aec30461ab |
Revert "[runtime] Remove extension slots from context objects"
This reverts commit
|
||
|
Victor Gomes
|
c07c02e1c4 |
[runtime] Remove extension slots from context objects
Context objects have an extension slot, which contains further additional data that depends on the type of the context. This CL removes the extension slot from contexts that don't need them, hence reducing memory. The following contexts will still have an extension slot: native, module, await, block and with contexts. See objects/contexts.h for what the slot is used for. The following contexts will not have an extension slot anymore (they were not used before): script, catch and builtin contexts. Eval and function contexts only have the extension slot if they contain a sloppy eval. Bug: v8:9744 Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 Commit-Queue: Victor Gomes <victorgomes@google.com> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Auto-Submit: Victor Gomes <victorgomes@google.com> Cr-Commit-Position: refs/heads/master@{#64372} |
||
Toon Verwaest
|
3cad6bf5d7 |
Reland^2 "[runtime] Move Context::native_context to the map"
This is a reland of
|
||
|
Sathya Gunasekaran
|
38301e7bb9 |
Revert "Reland "[runtime] Move Context::native_context to the map""
This reverts commit |
||
|
Toon Verwaest
|
c7c47c68f2 |
Reland "[runtime] Move Context::native_context to the map"
This is a reland of
|
||
|
Sathya Gunasekaran
|
586ec99bf9 |
Revert "[runtime] Move Context::native_context to the map"
This reverts commit
|
||
|
Toon Verwaest
|
f05bae1e0d |
[runtime] Move Context::native_context to the map
Remove the native context slot from contexts by making context maps native-context-specific. Now we require 2 loads to go from a context to the native context, but we have 1 field fewer to store when creating contexts. Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64296} |
||
|
Joyee Cheung
|
4e8c62819a |
[class] implement static private methods
This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219} |
||
|
Sathya Gunasekaran
|
5f0ef667c7 |
[class] Remove flags for class fields
Bug: v8:5367, v8:5368 Change-Id: I86f25f9f658e21a05604f3014e6ebf74f1a8a1f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1590164 Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61139} |
||
Mythri
|
4e321413d8 |
Allocate feedback cells in an array decoupled from other slots
This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147} |
||
Camillo Bruni
|
8b1b7deed6 |
[scope] Add Scope::ForEach helper to avoid recursion
Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253} |
||
|
Sathya Gunasekaran
|
1908872dcd |
[class] Make class field initializers breakable in the debugger
Add tests. Bug: v8:5367 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I2a4215a87ba1dae98c4b25547494165f534b4a66 Reviewed-on: https://chromium-review.googlesource.com/1218046 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#55974} |
||
|
Toon Verwaest
|
39496a95c5 |
Replace Context::closure with Context::scope_info, allowing closure to die.
There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952} |
||
Christian O. Andersson
|
894b95fe38 |
[ignition] Optimizing Smi only comparisons
There are various situations where we explicitly compare a SMI against another SMI (e.g., BuildIndexedJump). This is also a common pattern for generated code (e.g., comparing a loop variable with an integer). Instead of using the generic equality/strict-equality stub for this, which is expensive, this CL offers a simple comparison stub, repurposing the TestEqualStrictNoFeedback bytecode to TestReferenceEqual Bug: v8:5310 Change-Id: Ib2b47cd24d5386cf0d20d3bd794776dc6e3a02a5 Reviewed-on: https://chromium-review.googlesource.com/1007542 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Christian O. Andersson <cricke@chromium.org> Cr-Commit-Position: refs/heads/master@{#52655} |
||
|
Camillo Bruni
|
8255eeb936 |
[runtime] Add SCOPE_INFO_TYPE InstanceType
Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324} |
||
Daniel Ehrenberg
|
94d53d8742 |
[class] Split out static fields into a separate flag
This patch implements https://github.com/tc39/proposal-class-fields/pull/65 and https://github.com/tc39/proposal-static-class-features/ by splitting out instance and static field declarations into separate flags for the separate proposals. Instance class fields is currently at Stage 3 whereas static class fields is currently at Stage 2. Bug: v8:5367 Change-Id: I133c945fd0b22dc5718c7bb61b10f22348087acd Reviewed-on: https://chromium-review.googlesource.com/839778 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50293} |