- 11 Aug, 2022 1 commit
-
-
Darius M authored
StringConstantXXX were introduced when we switched to concurrent compilation, as a way to build strings in Turbofan in a background thread, without having to actually allocate them on the main heap from the background. See https://crrev.com/c/1221807. Now that we have local heaps, we can actually allocate strings from the background, making StringConstantXXX useless. Moreover, we would fold constant string concatenations into ConsString, which sounds a bit dubious for performance. Now, small constant string concatenations will be folded into SeqStrings, while larger ones will remain ConsString, just to avoid the quadratic worst-case. Change-Id: I0479d16aa5691c9d774187c4cc0d03ff4fe2b4f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811291Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#82381}
-
- 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}
-
- 23 Jun, 2022 1 commit
-
-
snek authored
Code for map methods was added a really long time ago but no one ever brought that to set. Adds new common lowering for both collections and updates the SetPrototypeHas builtin. My initial testing shows this to be as much as 50x faster in some cases. Change-Id: Ifea5be01c9e51013d57ac00bd817759ceace6669 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3709246Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: snek <snek@chromium.org> Cr-Commit-Position: refs/heads/main@{#81330}
-
- 07 Jun, 2022 1 commit
-
-
Nico Hartmann authored
In typed-optimization, Turbofan optimized NumberFloor(NumberDivide(...)) patterns where both inputs are known to be of Unsigned32 type, but the replacement couldn't be typed consistently. This CL introduces a new operator Unsigned32Divide, which has the same semantics, but can be typed consistently and thus allows the simplified lowering verifier to validate the graph correctly. Bug: v8:12619 Change-Id: Iad77154d3d840c94edfd3ab91ffa37c840da0bc9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644790 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#80967}
-
- 25 May, 2022 1 commit
-
-
Manos Koukoutos authored
We introduce wasm-gc specific nodes into the Turbofan IR, corresponding to the wasm opcodes: ref.as_non_null, ref.is_null, ref.null, rtt.canon, ref.test, ref.cast. We define them as simplified operators. These are lowered by a dedicated phase in the wasm pipeline. Optimizations based on these nodes will be introduced later. Note: We rename ObjectReferenceKnowledge to WasmTypeCheckConfig and move it to a separate file, as it is now used in simplified-operator as well. Bug: v8:7748 Change-Id: Iceaf04eca089b08bad794f567359196e8ba78d93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654102Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#80746}
-
- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 23 Mar, 2022 1 commit
-
-
Nico Hartmann authored
This reverts commit aaedd8b7. Changes in the reland: The inital problem was caused by nodes that were removed during SL because they are no-ops but have an effect on typing (in the repro, this was e.g. PlainPrimitiveToNumber). The reland introdocues a new operator SLVerifierHint that is used exclusively in SL to provide hints to the verifier and that solves this problem. SLVerifierHint also replaces the previous use of TypeGuard to type constant nodes for the verifier. Bug: v8:12619, chromium:1302572 Change-Id: I0957645c03d8b7c26cd6d630a1ecbd0a6a8223ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3512574Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#79564}
-
- 21 Mar, 2022 1 commit
-
-
Jakob Gruber authored
This CL removes: - Dynamic map checks aka minimorphic property loads (TF support, builtins). - "Bailout" deopts (= drop to the interpreter once, but don't throw out optimized code). - "EagerWithResume" deopts (= part of dynamic map check functionality, we call a builtin for the deopt check and deopt or resume based on the result). Fixed: v8:12552 Change-Id: I492cf1667e0f54586690b2f72a65ea804224b840 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401585 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#79544}
-
- 08 Mar, 2022 1 commit
-
-
Joyee Cheung authored
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/+/3481475Reviewed-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}
-
- 16 Feb, 2022 1 commit
-
-
Jakob Gruber authored
TierUpCheck and UpdateInterruptBudget were only used by Turboprop (likewise feedback_cell_node). Bug: v8:12552 Change-Id: Ic73d44a5734e183bc1a2eda58cdf85163220e4d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3463954 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#79116}
-
- 27 Dec, 2021 1 commit
-
-
Patrick Thier authored
This CL splits the TF type for JSFunction into CallableFunction and ClassConstructor. This differentiation allows us to lower calls to the CallFunction Builtin only for functions that we can actually call. Class Constructors are special, as they are callable but should raise an exception if called. By not lowering class constructors to calls to CallFunction (but the more generall Call) builtin, we can remove the checks for class constructors from CallFunction (in a follow-up CL). Bug: chromium:1262750 Change-Id: I399967eb03b2f20d2dcb67aef2243b32c9d3174e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350457Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#78445}
-
- 22 Dec, 2021 1 commit
-
-
Shu-yu Guo authored
Private method loads are compiled to a named load of a private brand, which always loads a BlockContext. This BlockContext holds the private methods common to all instances of a class. TurboFan currently considers JSLoadNamed to be of Type::NonInternal(). Private methods break this assumption, since BlockContext is of Type::OtherInternal(). This CL changes the typing of JSLoadNamed of private brands to be Type::OtherInternal(). Bug: v8:12500 Change-Id: I91f39747bf9422bd419d299f44152f567d8be8db Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3351167Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#78431}
-
- 09 Dec, 2021 1 commit
-
-
Manos Koukoutos authored
Design doc: bit.ly/36MfD6Y We introduce simplified operators LoadImmutableFromObject and InitializeImmutableInObject. These are lowered to Loads and Stores like LoadFromObject and StoreToObject. We split CsaLoadElimination::AbstractState in two HalfStates, which represent the mutable and immutable component of the state. Immutable operators in the effect chain modify the immutable half-state, and plain operators modify the mutable half-state. The immutable part is maintained through write effects and loop headers. Immutable initializations do not lookup and kill previous overlapping stores, assuming each offset cannot be initialized more than once. Bug: v8:11510 Change-Id: I0f5feca3354fdd3bdc1f511cc5214ec51e1407ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268728Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#78325}
-
- 23 Nov, 2021 1 commit
-
-
Tobias Tebbi authored
Private methods use a property with symbol name that stores a context. This is then loaded to perform the brand check. Since this uses JSLoadProperty in Turbofan, we should not type JSLoadProperty as NonInternal. Bug: chromium:1269063, v8:12359 Change-Id: I920ccf46e939ab0477ff2fdb3cda6d7d94bab0af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293089Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#78042}
-
- 28 Oct, 2021 1 commit
-
-
Tobias Tebbi authored
This is a reland of 45227ffd Differences: - Handle one more flags conflict in variants.py. - Disallow %VerifyType without --concurrent-recompilation. Original change's description: > [turbofan] extend type asserts to cover all JS types > > Extend type assertions to all types covering JavaScript values. > This is achieved by allocating type representations on the heap using > newly defined HeapObject subclasses. To allocate these in the compiler, > we disable concurrent compilation for the --assert-types flag for now. > > Fix two type errors that came up with the existing tests: > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of > OtherObject. > 2. OperationTyper::NumberToString(Type) can type the result as the > HeapConstant Factory::zero_string(). However, NumberToString does > not always produce this string. To avoid regressions, the CL keeps > the HeapConstant type and changes the runtime and builtin code to > always produce the canonical "0" string. > > A few tests were failing because they check for truncations to work > and prevent deoptimization. However, AssertType nodes destroy all > truncations (which is by design), so these tests are incompatible > and now disabled for the assert_types variant. > > Drive-by fix: a few minor Torque issues that came up. > > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77565} Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035 Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77596}
-
- 27 Oct, 2021 2 commits
-
-
Maya Lekova authored
This reverts commit 45227ffd. Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview Original change's description: > [turbofan] extend type asserts to cover all JS types > > Extend type assertions to all types covering JavaScript values. > This is achieved by allocating type representations on the heap using > newly defined HeapObject subclasses. To allocate these in the compiler, > we disable concurrent compilation for the --assert-types flag for now. > > Fix two type errors that came up with the existing tests: > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of > OtherObject. > 2. OperationTyper::NumberToString(Type) can type the result as the > HeapConstant Factory::zero_string(). However, NumberToString does > not always produce this string. To avoid regressions, the CL keeps > the HeapConstant type and changes the runtime and builtin code to > always produce the canonical "0" string. > > A few tests were failing because they check for truncations to work > and prevent deoptimization. However, AssertType nodes destroy all > truncations (which is by design), so these tests are incompatible > and now disabled for the assert_types variant. > > Drive-by fix: a few minor Torque issues that came up. > > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77565} Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034 Auto-Submit: Maya Lekova <mslekova@chromium.org> Owners-Override: Maya Lekova <mslekova@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#77566}
-
Tobias Tebbi authored
Extend type assertions to all types covering JavaScript values. This is achieved by allocating type representations on the heap using newly defined HeapObject subclasses. To allocate these in the compiler, we disable concurrent compilation for the --assert-types flag for now. Fix two type errors that came up with the existing tests: 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of OtherObject. 2. OperationTyper::NumberToString(Type) can type the result as the HeapConstant Factory::zero_string(). However, NumberToString does not always produce this string. To avoid regressions, the CL keeps the HeapConstant type and changes the runtime and builtin code to always produce the canonical "0" string. A few tests were failing because they check for truncations to work and prevent deoptimization. However, AssertType nodes destroy all truncations (which is by design), so these tests are incompatible and now disabled for the assert_types variant. Drive-by fix: a few minor Torque issues that came up. Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#77565}
-
- 13 Oct, 2021 1 commit
-
-
Joyee Cheung authored
Introduces several new runtime mechanics for defining private fields, including: - Bytecode StaKeyedPropertyAsDefine - Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback} - Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} - TurboFan IR opcode JSDefineProperty These new operations can reduce a runtime call per class field into a more traditional Store equivalent. In the microbenchmarks, this results in a substantial win over the status quo (~8x benchmark score for single fields with the changes, ~20x with multiple fields). The TurboFan JSDefineProperty op is lowered in JSNativeContextSpecialization, however this required some hacks. Because private fields are defined as DONT_ENUM when added to the object, we can't find a suitable transition using the typical data property (NONE) flags. I've added a mechanism to specify the required PropertyAttributes for the transition we want to look up. Details: New bytecodes: - StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty but with a different IC builtin (KeyedDefineOwnIC). This is a bytecode rather than a flag for the existing StaKeyedProperty in order to avoid impacting typical keyed stores in any way due to additional branching and testing. New builtins: - StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for StaNamedOwnProperty. Unlike the regular StoreIC, this variant will no longer look up the property name in the prototype. In adddition, this CL changes an assumption that StoreNamedOwnProperty can't result in a map transition, as we can't rely on the property already being present in the Map due to an object literal boilerplate. In the context of class features, this replaces the runtime function %CreateDataProperty(). - KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the new StaKeyedPropertyAsDefine bytecode. This is similar to an ordinary KeyedStoreIC, but will not check the prototype for setters, and for private fields, will take the slow path if the field already exists. In the context of class features, this replaces the runtime function %AddPrivateField(). TurboFan IR: - JSDefineProperty is introduced to represent a situation where we need to use "Define" semantics, in particular, it codifies that we do not consult the prototype chain, and the semantics relating to private fields are implied as well. R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org Bug: v8:9888 Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#77377}
-
- 01 Sep, 2021 1 commit
-
-
Jakob Gruber authored
JSFunctionData has a fairly heavy serialized payload, and likewise consistency validation validates many fields and thus has many opportunities to fail. We therefore want to avoid or reduce validation whenever possible. This CL adds tracking s.t. we know which fields were actually used, and we limit validation to used fields. Drive-by: Make serialized_ debug-only. Drive-by: Don't create deps for context/native_context/shared. Bug: v8:7790 Change-Id: Ic32c9919f0c75a76d9c36e4396b6bce383151b62 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3132962 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/main@{#76614}
-
- 17 Aug, 2021 1 commit
-
-
Georg Neis authored
The validation was too strong in the case where the incrementation produces type None. Bug: chromium:1236716 Change-Id: I948b370594fa7dad1ba6e5b951f473855bf1346b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097865Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76338}
-
- 12 Aug, 2021 1 commit
-
-
Ross McIlroy authored
These are no longer enabled, so remove the code mitigation logic from the codebase. BUG=chromium:1003890 Change-Id: I536bb1732e8463281c21da446bbba8f47ede8ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045704 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76256}
-
- 19 Jul, 2021 1 commit
-
-
Jakob Gruber authored
This wraps up the transition away from kSerialized ref kinds. Since JSFunctionRef is a complex type, we don't attempt full consistency on the background thread. Instead, we serialize functions on the background in a partially-racy manner, in which consistency between different JSFunction fields is *not* guaranteed. Consistency is later verified through a new compilation dependency kind during finalization. Bug: v8:7790, v8:12004 Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75789}
-
- 15 Jul, 2021 1 commit
-
-
Georg Neis authored
Bug: chromium:1228233 Change-Id: I7868cefd2123261f144d61e322a233ed460100ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026717 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#75732}
-
- 12 Jul, 2021 1 commit
-
-
Georg Neis authored
Monotonicity of typing of arithmetic operations could fail in the presence of optimized_out Oddball inputs, which can arise in dead code in resumable functions. The CL fixes these with a small change to BinaryNumberOpTyper. Bug: chromium:1227677 Change-Id: I1e1d2e174b757e839d776685f52f7c4ac900844b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020972Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#75683}
-
- 17 Jun, 2021 1 commit
-
-
Toon Verwaest authored
This also removes intrinsics that were just used in tests. It keeps InlineIncBlockCounter for now because it's a less straightforward. Change-Id: I77e55d7a746294892d0fd7ab577ebf8eb42f1f08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953195 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75217}
-
- 07 Jun, 2021 1 commit
-
-
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}
-
- 31 May, 2021 1 commit
-
-
Victor Gomes authored
Bug: chromium:1213927 Change-Id: I11729540d9f20b437411f0b9f8077be2a7f066b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922117Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74850}
-
- 05 May, 2021 1 commit
-
-
Nico Hartmann authored
This CL adds a new %VerifyType compiler intrinsic that can be used by tests and fuzzers to generate a runtime type check of the given input value. Internally, %VerifyType is lowered to %AssertType which is why checks are currently limited to range types. tests to be const-correct. Drive-by: Add a few consts to NodeProperties accessors to allow Bug: v8:11724 Change-Id: I06842062d0e8278a5ba011d5a09947fe05b6e85e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859959 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74377}
-
- 23 Apr, 2021 1 commit
-
-
Leszek Swirski authored
The ToString intrinsic isn't used anymore, since there is now a ToString bytecode, so we can remove it. Change-Id: I5ed121ae4d117660e1ee8a64a2b30e1fb054a886 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848465 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#74151}
-
- 11 Mar, 2021 3 commits
-
-
Clemens Backes authored
This is a reland of 80f5dfda. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
-
Clemens Backes authored
This reverts commit 80f5dfda. Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} Bug: v8:11238 Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73346}
-
Clemens Backes authored
This is the biggest chunk, including - all of src/wasm, - torque file for wasm objects, - torque file for wasm builtins, - wasm builtins, - wasm runtime functions, - int64 lowering, - simd scala lowering, - WasmGraphBuilder (TF graph construction for wasm), - wasm frame types, - wasm interrupts, - the JSWasmCall opcode, - wasm backing store allocation. Those components are all recursively entangled, so I found no way to split this change up further. Some includes that were recursively included by wasm headers needed to be added explicitly now. backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc because it only tests wasm backing stores. This file is excluded from no-wasm builds then. R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org Bug: v8:11238 Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73344}
-
- 05 Feb, 2021 1 commit
-
-
Paolo Severini authored
This is a reland of 6ada6a90 - Fixed a GC issue https://bugs.chromium.org/p/v8/issues/detail?id=11335: GC expected all arguments on the stack from code with CodeKind::TURBOFAN to be tagged objects. This is not the case now with inlined Wasm calls, and this information can be passed in SafepointEntry for each call site. - Disabled JS-to-Wasm inlining for calls inside try/catch. For more details, see updated doc: https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit# Bug: v8:11092 Original change's description: > Reland "Faster JS-to-Wasm calls" > > This is a reland of 860fcb1b > > - Disabled the tests for this feature in V8-lite mode (the original > change broke V8-lite tests). > - Also modified test console-profile-wasm.js that was brittle with this > change because it assumed that there was always a JS-to-Wasm wrapper > but this is not the case when the TurboFan compilation completes before > the Liftoff-compiled code starts to run. > > More changes in Patchset 8: > > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering, > into a new phase, wasm-inlining that reuses the JSInliner reducer. > The doc > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit# > describes the new logic. > > - Fixed a couple of small issues in wasm_compiler.cc to make sure that > the graph "JSToWasm Wrapper" subgraph has a valid Control chain; > this should solve the problem we had inlining the calls in functions > that can throw exception. Original change's description: > Faster JS-to-Wasm calls > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on > the basis of the signature of a Wasm function to call, and whose task > is to: > - set "thread_in_wasm_flag" to true > - convert the arguments from tagged types into Wasm native types > - calculate the address of the Wasm function to call and call it > - convert back the result from Wasm native types into tagged types > - reset "thread_in_wasm_flag" to false. > > This CL tries to improve the performance of JS-to-Wasm calls by > inlining the code of the JS-to-Wasm wrappers in the call site. > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for > this kind of calls. A 'JSWasmCall' node is associated to > WasmCallParameters, which contain information about the signature of > the Wasm function to call. > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid > generating code to convert the types for the arguments > of the Wasm function, when the conversion is not necessary. > The actual inlining of the graph generated for this wrapper happens in > the simplified-lowering phase. > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage > lazy deoptimizations that can happen if the Wasm function callee calls > back some JS code that invalidates the compiled JS caller function. > Bug: v8:11092 Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777 Commit-Queue: Paolo Severini <paolosev@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72541}
-
- 27 Jan, 2021 1 commit
-
-
Jakob Gruber authored
Start nodes for JS functions have the following Parameter node value outputs: closure, ...args_including_receiver, new_target, argc, context This CL adds helper functions for these. There's two interesting gotcha's: - Each Parameter node is associated with an index, starting at -1. Value output indices obviously start at 0, so there's an off-by-one between the value output of the Parameter node, and the Parameter node's associated index. - CSA/Torque graphs use different Start node layouts, yet these are not reflected in compiler logic. There's potential for confusion here. The two layouts should be unified or made explicit. Finally, tests create Start nodes with arbitrary layouts. This blocks removal of methods marked _MaybeNonStandardLayout. In an ideal world, the parameter index would equal the start node output index, and the layout of all Start nodes would be equal. Future work.. Change-Id: I908909880817979062d459b7a80ed4fede40e2ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649035 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72352}
-
- 22 Jan, 2021 2 commits
-
-
Victor Gomes authored
After removing the arguments adaptor frame, this should not be needed anymore. Removes ArgumentFrame from the following nodes: - ArgumentsLength - RestLength - NewArgumentsElements Also removes 'formal parameter count' as input of ArgumentsLength. Adapt the escape analysis to use the frame pointer directly instead of the ArgumentsFrame node. Change-Id: I0ead48a6ee05a10d05d6cfa2e46906ad69930986 Bug: v8:11306 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639765 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72264}
-
Paolo Severini authored
This reverts commit 6ada6a90. Reason for revert: Revert for link issue: https://bugs.chromium.org/p/v8/issues/detail?id=11335 Original change's description: > Reland "Faster JS-to-Wasm calls" > > This is a reland of 860fcb1b > > - Disabled the tests for this feature in V8-lite mode (the original > change broke V8-lite tests) > - Also modified test console-profile-wasm.js that was brittle with this > change because it assumed that there was always a JS-to-Wasm wrapper > but this is not the case when the TurboFan compilation completes before > the Liftoff-compiled code starts to run. > > More changes in Patchset 8: > > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering, > into a new phase, wasm-inlining that reuses the JSInliner reducer. > The doc > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit# > describes the new logic. > > - Fixed a couple of small issues in wasm_compiler.cc to make sure that > the graph "JSToWasm Wrapper" subgraph has a valid Control chain; > this should solve the problem we had inlining the calls in functions > that can throw exception. > > > Original change's description: > > Faster JS-to-Wasm calls > > > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. > > > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on > > the basis of the signature of a Wasm function to call, and whose task > > is to: > > - set "thread_in_wasm_flag" to true > > - convert the arguments from tagged types into Wasm native types > > - calculate the address of the Wasm function to call and call it > > - convert back the result from Wasm native types into tagged types > > - reset "thread_in_wasm_flag" to false. > > > > This CL tries to improve the performance of JS-to-Wasm calls by > > inlining the code of the JS-to-Wasm wrappers in the call site. > > > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for > > this kind of calls. A 'JSWasmCall' node is associated to > > WasmCallParameters, which contain information about the signature of > > the Wasm function to call. > > > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments > > of the Wasm function, when the conversion is not necessary. > > The actual inlining of the graph generated for this wrapper happens in > > the simplified-lowering phase. > > > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage > > lazy deoptimizations that can happen if the Wasm function callee calls > > back some JS code that invalidates the compiled JS caller function. > > > > Bug: v8:11092 > > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538 > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > > Cr-Commit-Position: refs/heads/master@{#71824} > > Bug: v8:11092 > Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng > Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72147} Tbr: ahaas@chromium.org, jgruber@chromium.org Bug: v8:11092, v8:11335 Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6 Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72253}
-
- 19 Jan, 2021 1 commit
-
-
Paolo Severini authored
This is a reland of 860fcb1b - Disabled the tests for this feature in V8-lite mode (the original change broke V8-lite tests) - Also modified test console-profile-wasm.js that was brittle with this change because it assumed that there was always a JS-to-Wasm wrapper but this is not the case when the TurboFan compilation completes before the Liftoff-compiled code starts to run. More changes in Patchset 8: - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering, into a new phase, wasm-inlining that reuses the JSInliner reducer. The doc https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit# describes the new logic. - Fixed a couple of small issues in wasm_compiler.cc to make sure that the graph "JSToWasm Wrapper" subgraph has a valid Control chain; this should solve the problem we had inlining the calls in functions that can throw exception. Original change's description: > Faster JS-to-Wasm calls > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on > the basis of the signature of a Wasm function to call, and whose task > is to: > - set "thread_in_wasm_flag" to true > - convert the arguments from tagged types into Wasm native types > - calculate the address of the Wasm function to call and call it > - convert back the result from Wasm native types into tagged types > - reset "thread_in_wasm_flag" to false. > > This CL tries to improve the performance of JS-to-Wasm calls by > inlining the code of the JS-to-Wasm wrappers in the call site. > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for > this kind of calls. A 'JSWasmCall' node is associated to > WasmCallParameters, which contain information about the signature of > the Wasm function to call. > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments > of the Wasm function, when the conversion is not necessary. > The actual inlining of the graph generated for this wrapper happens in > the simplified-lowering phase. > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage > lazy deoptimizations that can happen if the Wasm function callee calls > back some JS code that invalidates the compiled JS caller function. > > Bug: v8:11092 > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#71824} Bug: v8:11092 Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72147}
-
- 17 Dec, 2020 2 commits
-
-
Nico Hartmann authored
This reverts commit 860fcb1b. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview Original change's description: > Faster JS-to-Wasm calls > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on > the basis of the signature of a Wasm function to call, and whose task > is to: > - set "thread_in_wasm_flag" to true > - convert the arguments from tagged types into Wasm native types > - calculate the address of the Wasm function to call and call it > - convert back the result from Wasm native types into tagged types > - reset "thread_in_wasm_flag" to false. > > This CL tries to improve the performance of JS-to-Wasm calls by > inlining the code of the JS-to-Wasm wrappers in the call site. > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for > this kind of calls. A 'JSWasmCall' node is associated to > WasmCallParameters, which contain information about the signature of > the Wasm function to call. > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments > of the Wasm function, when the conversion is not necessary. > The actual inlining of the graph generated for this wrapper happens in > the simplified-lowering phase. > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage > lazy deoptimizations that can happen if the Wasm function callee calls > back some JS code that invalidates the compiled JS caller function. > > Bug: v8:11092 > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#71824} TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:11092 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71825}
-
Paolo Severini authored
This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. Currently JS-to-Wasm calls go through a wrapper/trampoline, built on the basis of the signature of a Wasm function to call, and whose task is to: - set "thread_in_wasm_flag" to true - convert the arguments from tagged types into Wasm native types - calculate the address of the Wasm function to call and call it - convert back the result from Wasm native types into tagged types - reset "thread_in_wasm_flag" to false. This CL tries to improve the performance of JS-to-Wasm calls by inlining the code of the JS-to-Wasm wrappers in the call site. It introduces a new IR operand, JSWasmCall, which replaces JSCall for this kind of calls. A 'JSWasmCall' node is associated to WasmCallParameters, which contain information about the signature of the Wasm function to call. WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments of the Wasm function, when the conversion is not necessary. The actual inlining of the graph generated for this wrapper happens in the simplified-lowering phase. A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage lazy deoptimizations that can happen if the Wasm function callee calls back some JS code that invalidates the compiled JS caller function. Bug: v8:11092 Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis (ooo until January 5) <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71824}
-
- 02 Dec, 2020 1 commit
-
-
Ross McIlroy authored
Unifies various operators for dynamic map checks with the naming scheme of DynamicCheckMaps (to be similar to CheckMaps. BUG=v8:10582 Change-Id: I8ac842f55fe31cdc7b84968d077017a86ddf4442 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567952 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71559}
-