- 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}
-
- 01 Dec, 2020 1 commit
-
-
Ross McIlroy authored
In order to reduce the codegen size of dynamic map checks, add the ability to have an eager with resume deopt point, which can call a given builitin to perform a more detailed check than can be done in codegen, and then either deoptimizes itself (as if the calling code had performed an eager deopt) or resumes execution in the calling code after the check. In addition, support for adding extra arguments to a deoptimization continuation is added to enable us to pass the necessary arguments to the DynamicMapChecks builtin. Finally, a trampoline is added to the DynamicMapChecks which saves the registers that might be clobbered by that builtin, to avoid having to save them in the generated code. This trampoline also performs the deoptimization based on the result of the DynamicMapChecks builtin. In order to ensure both the trampoline and DynamicMapChecks builtin have the same call interface, and to limit the number of registers that need saving in the trampoline, the DynamicMapChecks builtin is moved to be a CSA builtin with a custom CallInterfaceDescriptor, that calls an exported Torque macro that implements the actual functionality. All told, this changes the codegen for a monomorphic dynamic map check from: movl rbx,<expected_map> cmpl [<object>-0x1],rbx jnz <deferred_call> resume_point: ... deferred_call: <spill registers> movl rax,<slot> movq rbx,<object> movq rcx,<handler> movq r10,<DynamicMapChecks> call r10 cmpq rax,0x0 jz <restore_regs> cmpq rax,0x1 jz <deopt_point_1> cmpq rax,0x2 jz <deopt_point_2> int3l restore_regs: <restore_regs> jmp <resume_point> ... deopt_point_1: call Deoptimization_Eager deopt_point_2: call Deoptimization_Bailout To: movl rax,<slot> movl rcx,<expected_map> movq rdx,<handler> cmpl [<object>-0x1],rcx jnz <deopt_point> resume_point: ... deopt_point: call DynamicMapChecksTrampoline jmp <resume_point> BUG=v8:10582 Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71545}
-
- 29 Oct, 2020 1 commit
-
-
Shu-yu Guo authored
Fix super calls so that arguments are evaluated before the super constructor is checked to be in fact a constructor. A new bytecode is introduced to split the IsConstructor check out from the current GetSuperConstructor bytecode. Bug: v8:10111 Change-Id: I3af99e32a34d99493806bb01b547d6f671cdc9de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493077 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70881}
-
- 25 Sep, 2020 1 commit
-
-
Bill Budge authored
Bug: v8:10933 Change-Id: I4db540cf47ce5cfa25757d776a2bf988ce3ed554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432072Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#70147}
-
- 11 Sep, 2020 1 commit
-
-
Georg Neis authored
... by unparking the local heap before accessing the handles. Bug: v8:7790 Change-Id: I0910fd8ad2a1e9cbbf312acb4f26358a09891f0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404455Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69852}
-