- 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}
-
- 07 Jul, 2022 1 commit
-
-
Manos Koukoutos authored
Mostly src/codegen, src/compiler, src/snapshot, src/utils. Bug: v8:13006 Change-Id: I2fb31acc749a7376e6f2a7424ed2e67ff479d971 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749178 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81575}
-
- 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}
-
- 05 May, 2022 1 commit
-
-
Peter Kasting authored
This prevents ambiguity errors in C++20 due to ADL when casting types in std::, which gains std::bit_cast<>(). Bug: chromium:1284275 Change-Id: I25046d1952a9304852e481ad8b84049c6769c289 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625838 Auto-Submit: Peter Kasting <pkasting@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80378}
-
- 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}
-
- 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}
-
- 05 Aug, 2021 2 commits
-
-
Jakob Gruber authored
Bug: v8:7790 Change-Id: Ia5903364a774bd49db1a646b3066b9972deac725 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074465 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76119}
-
Jakob Gruber authored
Bug: v8:7790 Change-Id: I299678102254ffb7d68be3d5cad11b4a4161492f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068947 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76118}
-
- 08 Jul, 2021 1 commit
-
-
Georg Neis authored
Optimize JSCallWithArrayLike with diamond speculation when probable arguments list is empty literal array The JSCallWithArraylike can be replaced with a JSCall if its probable arguments list is empty literal array. This replacement will introduce a deoptimization check to make sure the length of arguments list is 0 at runtime. This CL change this optimization to a diamond speculation which may help avoid deoptimization once and keep the fast path. This change may benefit a following usecase, function calcMax(testArray) { Array.max = function(array) { return Math.max.apply(Math, array); }; var result = []; for (var i = 0; i < testArray.length - 3; i++) { var positiveNumbers = []; for (var j = 0; j < 3; j++) { if (testArray[i + j] > 0) { positiveNumbers.push(testArray[i + j]); } } result.push(Array.max(positiveNumbers)); } return result; } testArray = [-1, 2, 3, -4, -5, -6, -7, -8, -9, 10]; for (var i = 0; i < 1000000; i++) { calcMax(testArray); } Bug: v8:9974 Change-Id: I595627e2fd937527350c8f8652d701c791b41dd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967757 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#75636}
-
- 17 Jun, 2021 1 commit
-
-
Igor Sheludko authored
This CL adds - CodeT type - an alias for CodeDataContainer or Code depending on whether the v8_enable_external_code_space is enabled or not, - a set of conversion functions from CodeT to Code or CodeDataContainer and back (both in C++ and CodeStubAssembler), - masm support for calling/tailcalling via CallDataContainer which contain the code entry point address, - masm support for calling/tailcalling via CodeT. Bug: v8:11880 Change-Id: Ib36f4c6db69ec49aaea29412647e59ada95da19b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967463 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75207}
-
- 27 May, 2021 1 commit
-
-
Lei Zhang authored
As is, the DCHECK() has a #if inside, and MSVC has trouble pre-processing that. Fix this by moving the conditional inside the DCHECK() into a separate helper function. Bug: v8:11760 Change-Id: Ib4ae0fe263029bb426da378afa5b6881557ce652 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919421Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#74807}
-
- 11 May, 2021 1 commit
-
-
Camillo Bruni authored
Convert StoreOrigin, TypeOfMode, SaveFPRegsMode and ArgvMode to enum classes with k-prefixed values. Change-Id: Ib6ca3a9995297e8303a7e013b1d829613c0db510 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2885042Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74497}
-
- 10 May, 2021 1 commit
-
-
Clemens Backes authored
After updating our bots to use GCC 7.4, we do not need to support incomplete C++14 support any more. In particular, we can assume complete c++14 constexpr support now. This CL removes the V8_HAS_CXX14_CONSTEXPR and CONSTEXPR_DCHECK macros. The CONSTEXPR_DCHECKs are replaced by DCHECK and friend, or STATIC_ASSERT where possible. R=jgruber@chromium.org, leszeks@chromium.org, mlippautz@chromium.org Bug: v8:9686, v8:11384 Change-Id: I3a8769a0f54da7eb2cacc37ee23e5c97092e3051 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876847Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74486}
-
- 06 May, 2021 1 commit
-
-
Fanchen Kong authored
When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer: receiver.apply(this, args) -> this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target is not a heapconstant. With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%. function reduceArray(func, arr, r) { for (var i = 0, len = arr.length; i < len; i++) { r = func.apply(null, r, arr[i]); } return r; } var a = 0; for (var i = 0; i < 10000000; i++) { a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1); } console.log(a); This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls. Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74413}
-
- 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}
-
- 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}
-
- 22 Jan, 2021 1 commit
-
-
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}
-
- 20 Jan, 2021 1 commit
-
-
Jakob Gruber authored
Move index constants into the wrapper, add getters, and use the wrapper in more spots. Bug: v8:1166136 Change-Id: I3f37a541482fd6b7c604719c759952a72d58bad2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637218 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72198}
-
- 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}
-
- 12 Nov, 2020 1 commit
-
-
Marja Hölttä authored
Bug: v8:9237 Change-Id: I1e308a5a325b01fcdc9236f13080653f3be6d328 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527095 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71155}
-
- 10 Nov, 2020 1 commit
-
-
Marja Hölttä authored
This is the second reland of https://chromium-review.googlesource.com/c/v8/v8/+/2487122 , this time without RuntimeCallStats in the tests. Generalize the existing property lookup machinery (JSNCS::ReduceNamedAccess) to handle the case where the lookup_start_object and the receiver are different objects. Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit#heading=h.xqthbgih7l2l Bug: v8:9237 Change-Id: I782df6e032ff8191082b425e68d68b69cef0a560 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527092 Auto-Submit: Marja Hölttä <marja@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71077}
-
- 09 Nov, 2020 2 commits
-
-
Shu-yu Guo authored
This reverts commit 30ca51ec. Reason for revert: TSAN failures https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34104 Original change's description: > [super] Optimize super property access in JSNativeContextSpecialization > > This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/2487122 > > Generalize the existing property lookup machinery > (JSNCS::ReduceNamedAccess) to handle the case where the > lookup_start_object and the receiver are different objects. > > Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit#heading=h.xqthbgih7l2l > > Bug: v8:9237 > Change-Id: Ia8e79b00f7720f4e3e90801e49a0106e03b4767d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523197 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71052} TBR=marja@chromium.org,neis@chromium.org Change-Id: I2b10963a9a99f7b482f1014472a6a281fcf9b8c1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527184Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#71058}
-
Marja Hölttä authored
This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/2487122 Generalize the existing property lookup machinery (JSNCS::ReduceNamedAccess) to handle the case where the lookup_start_object and the receiver are different objects. Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit#heading=h.xqthbgih7l2l Bug: v8:9237 Change-Id: Ia8e79b00f7720f4e3e90801e49a0106e03b4767d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523197 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71052}
-
- 06 Nov, 2020 1 commit
-
-
Nico Hartmann authored
Bug: v8:11074 Change-Id: I6d58d523254915a6b0d6542d8f80ddc6cee71dee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520907Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71003}
-
- 05 Nov, 2020 2 commits
-
-
Clemens Backes authored
This reverts commit 0147db5a. Reason for revert: Data races: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34056 Original change's description: > [super] Optimize super property access in JSNativeContextSpecialization > > Generalize the existing property lookup machinery > (JSNCS::ReduceNamedAccess) to handle the case where the > lookup_start_object and the receiver are different objects. > > Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit#heading=h.xqthbgih7l2l > > Bug: v8:9237 > Change-Id: I28b6d87ce6537acd8cf972bbe7dc6d63d581aadc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487122 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70988} TBR=marja@chromium.org,mvstanton@chromium.org,neis@chromium.org Change-Id: Ib5ddb919ae569fe5ddf266d986f1c8bc0fe9621a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520908Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70992}
-
Marja Hölttä authored
Generalize the existing property lookup machinery (JSNCS::ReduceNamedAccess) to handle the case where the lookup_start_object and the receiver are different objects. Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit#heading=h.xqthbgih7l2l Bug: v8:9237 Change-Id: I28b6d87ce6537acd8cf972bbe7dc6d63d581aadc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487122 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#70988}
-
- 14 Oct, 2020 1 commit
-
-
Jakob Gruber authored
This is a reland of 16cd5995 Changes since the original CL: generic lowering support for ForInPrepare and ForInNext. Original change's description: > [nci] Prepare JSForInPrepare and JSForInNext for feedback input > > These two operators are still missing feedback collection in generic > lowering (reminder: all operations that collect FB in the interpreter > must also collect FB in generic lowering). > > This CL prepares for that by adding the feedback vector as an input, > and additionally adds node wrappers to improve useability. > > The actual collection logic will be added in a following CL. > > Bug: v8:8888 > Change-Id: I04627eedb2dc237dc4e417091c44d2a95bd98f5f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454712 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70372} Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:8888 Change-Id: Idc294ffd2a24922edd08db6897d32d5724956995 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459373 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70496}
-
- 07 Oct, 2020 2 commits
-
-
Jakob Gruber authored
This reverts commit 16cd5995. Reason for revert: Can't be landed without also implementing generic lowering, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20fyi/18261. Original change's description: > [nci] Prepare JSForInPrepare and JSForInNext for feedback input > > These two operators are still missing feedback collection in generic > lowering (reminder: all operations that collect FB in the interpreter > must also collect FB in generic lowering). > > This CL prepares for that by adding the feedback vector as an input, > and additionally adds node wrappers to improve useability. > > The actual collection logic will be added in a following CL. > > Bug: v8:8888 > Change-Id: I04627eedb2dc237dc4e417091c44d2a95bd98f5f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454712 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70372} TBR=jgruber@chromium.org,leszeks@chromium.org,tebbi@chromium.org Change-Id: Ibff2bf44eb04bebd982b019b4539275db75c611a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8888 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454078Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70376}
-
Jakob Gruber authored
These two operators are still missing feedback collection in generic lowering (reminder: all operations that collect FB in the interpreter must also collect FB in generic lowering). This CL prepares for that by adding the feedback vector as an input, and additionally adds node wrappers to improve useability. The actual collection logic will be added in a following CL. Bug: v8:8888 Change-Id: I04627eedb2dc237dc4e417091c44d2a95bd98f5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454712 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70372}
-
- 28 Aug, 2020 1 commit
-
-
Marja Hölttä authored
This is the first step in a series of CLs. The goal is to make super property access faster. Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit?usp=sharing This CL: - Add bytecode LdaNamedPropertyFromSuper - IGNITION_HANDLER just calls Runtime::LoadFromSuper - JSGenericLowering::LowerJSLoadNamedFromSuper just replaces the node with a runtime call to Runtime::LoadFromSuper Bug: v8:9237 Change-Id: Id28e935294c5068dd6c54e6b860a77d61517fff5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327912 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69604}
-
- 15 Jul, 2020 1 commit
-
-
Georg Neis authored
Make JSContextSpecialization constant-fold import.meta loads if the meta object has already been created. Most of this CL was contributed by Gus Caplan. This is a verbatim copy of CL https://chromium-review.googlesource.com/c/v8/v8/+/2170982 which could not be landed due to the wrong email address being used. TBR=verwaest@chromium.org TBR=gsathya@chromium.org Bug: v8:7044 Change-Id: Ief45f3082dc756265904ff500305d32717071e81 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299375Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68875}
-
- 07 Jul, 2020 1 commit
-
-
Jakob Gruber authored
HasProperty and InstanceOf now both have a feedback vector input, and collect feedback in generic lowering. CreateClosure loads the feedback cell (in nci mode) instead of embedding a heap constant. Bug: v8:8888 Change-Id: Id479cda344684aeb5054f687b087c4fedeac05d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282530Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68711}
-
- 06 Jul, 2020 3 commits
-
-
Jakob Gruber authored
This is the last batch of operators which used to embed the feedback vector as a HeapConstant: - CreateEmptyLiteralArray - LoadGlobal - LoadNamed - StoreDataPropertyInLiteral - StoreGlobal - StoreInArrayLiteral - StoreNamed - StoreNamedOwn They now take the vector as an input. In NCI mode, the vector is loaded from the closure at the beginning of the function. Bug: v8:8888 Change-Id: Ifd2d2a556db343512b61e099a73702822b1ba9f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282525 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68695}
-
Jakob Gruber authored
Prior to this CL, the construct node layout was: {target, args..., new_target} The new layout is: {target, new_target, args..., feedback_vector} Having new_target at index 1 brings it closer to call node layout, which is now identical except that it has receiver at index 1. The new feedback vector input will be needed for NCI code. Affected node kinds are: - JSConstruct - JSConstructWithArrayLike - JSConstructWithSpread - JSConstructForwardVarargs (just the new_target position change) Bug: v8:8888 Change-Id: I4c68a0901d01e8862fd276c8a858799d5f4ff024 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2278475 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68692}
-
Jakob Gruber authored
... in preparation for upcoming changes to 1. make construct node layout more consistent with call nodes by placing new_target (construct) in the same spot as receiver (call); and 2. adding the feedback vector input. Bug: v8:8888 Change-Id: I6cd7f50ed0b029de53af5cd82e7ecf4ba514ef65 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2275963 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68689}
-