- 14 Jul, 2020 1 commit
-
-
Jakob Kummerow authored
The named LoadIC code was missing a check for "names" that convert to TypedArray indices. This was flushed out by the recent bump of the max TypedArray size from 2^32-1 to 2^32. Named StoreICs had the same bug; fixed here as well. Bug: v8:4153 Fixed: chromium:1104608 Change-Id: I6bd2552d6ccc238104f92e7b95d19970d4a75dae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295606Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68840}
-
- 10 Jul, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Since we are not using CodeAssemblerVariables anymore, we can properly scope the class so that the only way to instance one is through the typed version (i.e TypedCodeAssemblerVariable). Bug: v8:6949 Change-Id: I3ee99bcbb9421aadd0944af57f6452e832719758 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2290858 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68797}
-
- 09 Jul, 2020 1 commit
-
-
Leszek Swirski authored
Change-Id: I90612ae0e54b46e7147d9a3392783f56da598b2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287499 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68750}
-
- 04 Jun, 2020 2 commits
-
-
Nico Hartmann authored
Speculative BigInt addition fails to throw the expected exception when called with non-BigInt inputs when the result of the computation is unused. In paricular, this CL does: - Remove kNoThrow on speculative BigInt operators - Fix AddWithFeedback to not lose type feedback if builtin throws to elide existing deopt loops - Add handling of TypeCheckKind in RepresentationChanger where this was previously ignored Bug: chromium:1073440 Change-Id: I953a5b790fc3b37a6824f0b6546a0488c51fbb3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228493Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68181}
-
Mythri A authored
We use StoreOwnIC to initialize the object after creating a new object with CreateObjectLiteral. CreateObjectLiteral stores kHoleNaNInt64 to indicate an uninitialized double field. When we actually try to store a NaN value into that field later using StoreOwnIC, IC avoids actually storing the new value since the existing value is "same as" the value we try to write. The float comparison treats all NaNs as equal. In this particular case, we should actually store the new value since kHoleNaNInt64 value is used to represent an uninitialized field. This cl just stores the new value even when the existing value is same as the new value for double fields. The check is still required to correctly track const fields. Bug: chromium:1082293 Change-Id: Ib37061802f2403545cffa6d6fef08be074b0825d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228886Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#68167}
-
- 28 May, 2020 1 commit
-
-
Nico Hartmann authored
In BinaryOpAssembler::Generate_BinaryOperationWithFeedback, the feedback is stored only after the respective builtin/runtime call. If this call throws an exception, the feedback is lost, leading to a deopt loop in some cases. This CL fixes that issue by writing the gathered feedback before passing control to the builtin. Bug: chromium:1077197, v8:9441 Change-Id: I20e4b14815520224e2c6f8af1af6a89f754ccddf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202904 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68038}
-
- 27 May, 2020 1 commit
-
-
Jakob Gruber authored
This CL brings unary op assembler structure closer to that of binary ops assemblers: - Decrement, Increment, Negate call into UnaryOpWithFeedback, - which takes lambdas specifying smi, float, and bigint logic. - BitwiseNot is different in that it still dispatches using TaggedToWOrd32OrBigIntWithFeedback. - These methods are all implemented in the (hidden) UnaryOpAssemblerImpl class. - The header only exposes UnaryOpAssembler with the bare minimum of API. The last point is the remaining major divergence from binary op assemblers. I just like how this avoids useless implementation details in the header. Bug: v8:8888 Change-Id: I0ac4695483950356885301234d58c1900904aa92 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214830 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68004}
-
- 25 May, 2020 1 commit
-
-
Jakob Gruber authored
This CL adds the new _WithFeedback variant of unary, binary, and compare operation builtins. Existing logic to do these operations is refactored s.t. it can be used by both ignition bytecode handlers and the new builtins. Note that the new builtins are not yet used. Follow-up CLs will hook them into generic lowering. Bug: v8:8888 Change-Id: Id77dbe74bdf3b3806b2aefdf1abe52c3d165a3a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208862 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67956}
-
- 18 May, 2020 1 commit
-
-
Santiago Aboy Solanes authored
There are some 'mode' still pending removal. Bug: v8:9708, v8:10506, v8:6949 Change-Id: Ie1dc0397241bf046ac9737666e700b98018b2ff5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202906 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#67861}
-
- 13 May, 2020 1 commit
-
-
Igor Sheludko authored
... when one of the receivers is a JSArray that may have a read-only length. Bug: chromium:1069530 Change-Id: Idbaf1a9030bb5a0f9c25e30925f18f603a99832f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196353Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#67783}
-
- 11 May, 2020 1 commit
-
-
Igor Sheludko authored
... when the element is read-only in one of the prototypes: * the length should not be updated, * in strict mode the store operation should throw TypeError. Bug: chromium:1055138 Change-Id: I7fc08e22c83f8a9848053cfe20851dc1b82f0e3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172090 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67717}
-
- 30 Apr, 2020 1 commit
-
-
Igor Sheludko authored
Bug: v8:10391 Change-Id: Ie019eb6253fdd29bfbae6a9f77c8b3396dacb599 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134141 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67488}
-
- 20 Apr, 2020 1 commit
-
-
Mythri A authored
The fast store handlers create elements and if we have a typed array on the prototype chain it is not easy to check when it is OK to create new elements. The TypedArrays swallow all OOB stores, and there is no easy way to check if the current store is OOB for JSObjects. So use slow stub when there are typed arrays on the prorotype chain of JSObjects. Bug: chromium:1068492 Change-Id: I9eea9cf00e3eb84931c5545d18ba53c4ec39f353 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134138 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#67226}
-
- 15 Apr, 2020 2 commits
-
-
Leszek Swirski authored
Soft-deopt for mono/polymorphic property accesses that don't have any maps, and only allow zero-map feedback to be monomorphic. This makes sure we only emit a megamorphic LoadIC builtin call if the IC was actually megamorphic. JSGenericLowering assumed that zero maps meant that a load site is megamorphic. However, it can be the case that the call-site is monomorphic or polymorphic, and the maps had died. In this case we don't want to call the megamorphic IC builtin, as on a stub cache miss we fallback to a normal LoadIC miss, which can record mono/polymorphic feedback in the IC. After this, we'll enter a miss loop in the megamorphic load builtin, and worse the LoadIC assumes that there's something "wrong" with the feedback, so it'll keep trying to reconfigure the handler (possibly allocating new load handlers if this is a prototype field access). As a drive-by, rewrite GetRelevantReceiverMaps to be an in-place filtering of the maps rather than copying them. Change-Id: I0c25bfa606367fa81c43223bbd56cdadb5e789ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150586Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67152}
-
Mythri A authored
In strict mode stores to non-existent properties throw. We should not install a handler with the property cell for such stores. These handlers would expect that the value exists when they see a property cell. If this property cell gets invalidated later, it appears as if it is a valid property cell with undefined value. This leads to an incorrect behaviour. This cl checks if we are in strict mode and uses a slow stub in such cases. Bug: chromium:1067757 Change-Id: I543c6a6931530bfb13cc9a33d1dabaa756489fd1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142255 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#67151}
-
- 03 Apr, 2020 1 commit
-
-
Bruce Dawson authored
This reverts commit 10360127. Reason for revert: This fix only had moderate impact and the underlying CPU bug has now been addressed. Original change's description: > Speculative fix to crashes from a CPU bug > > For the last few months Chrome has been seeing many "impossible" crashes > on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes > only happen with 64-bit Chrome and only happen in the prologue of two > functions. The crashes come and go across different Chrome versions. > Analysis of most of the crashes shows that the address of the crashing > instruction follows some patterns: > > When crashing in GetFieldIndex() the last byte of the address is always > 1c, 5c, 9c, or dc. > > When crashing in UpdateCaches (fewer unique samples) the last byte of > the address is always 5d or 9d. > > The address of the function is 0xc or 0xd bytes earlier so the crashing > functions always start with an address that ends in 10, 50, 90, or d0. > > Those addresses are for the crashes on a load of the __security_cookie. > The crashes also occasionally happen on the two instructions that follow > the __security_cookie load in which case the crashing instruction's > address has been seen to end with 23 or a3. This corresponds to a > function start address of 10 or 90. > > Since the crash involves reading incorrect instruction bytes when > crossing a 16-byte boundary and since the crash appears to only happen > with particular 16-byte alignments it seems reasonable to force the > function's alignments to a multiple of 32 to see if this reliably > avoids the crashes. This change uses the gcc/clang __attribute__ > directive to force 32-byte alignment. I have tested this change enough to > verify that it triggers the desired alignment (with up to 31 "int 3" > instructions added for padding) but since I have never reproduced this > crash I have no way of testing its efficacy. > > Bug: chromium:968683, chromium:964273 > Change-Id: Ia6e1c6d1e044b84d274817374b25523303e78b51 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803775 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63804} TBR=brucedawson@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:968683, chromium:964273 Change-Id: I150ecfebeff95e8f63dbba74d78491867dc17736 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134728 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66977}
-
- 02 Apr, 2020 1 commit
-
-
Mythri A authored
For keyed stores we recompute handlers based on the receiver maps we have seen. This is done so that we can transition to the most generic elements kind we have seen so far. When we recompute this handlers we get a new prototype validity cell and ignore the existing cell. This leads to incorrect behaviour if the cell was invalid. Recomputing the handler may be extra work which is not worth doing at this point. So we just reuse the existing validity cell and let the IC recompute the handler if we see the map again. Bug: chromium:1053939 Change-Id: Ifc891d70f5a4b8b774238e12fb40e29b4d174e37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122032 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66963}
-
- 31 Mar, 2020 1 commit
-
-
Joyee Cheung authored
Previously we use the error message for normal invalid private member access, so for a failed brand check for class C, the error is TypeError: Cannot read private member C from an object whose class did not declare it This updates the message to TypeError: Object must be an instance of class C Bug: v8:8330 Change-Id: Ida98f46b8387631194a9b7a48bd1f419045ac6e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100688 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66923}
-
- 20 Mar, 2020 1 commit
-
-
Victor Gomes authored
Bug: v8:10201 Change-Id: I72cbe15912395b9b06ffdccce935abae6e7a050e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093508Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66808}
-
- 13 Mar, 2020 1 commit
-
-
Jakob Kummerow authored
to properly choose named or indexed mode Bug: chromium:1059738 Change-Id: Icd086fee31079f52770742afa54fc946acb1fd81 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101005 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66702}
-
- 09 Mar, 2020 1 commit
-
-
Jakob Kummerow authored
Considering that the security benefit is unclear at this point, the performance and binary size costs are not justified. This CL includes reverts of earlier partial disablings: 173a2bd8 af7bf14f 85f72be3 Bug: chromium:977230, chromium:1055312, chromium:1055317 Change-Id: I173b61656a542687c4619fa374a0b2ee22c85ef7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091474Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Hablich <hablich@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66623}
-
- 04 Mar, 2020 1 commit
-
-
Igor Sheludko authored
This CL simplifies IC code since we no longer need to keep feedback slot indices in both Smi and IntPtr form and as a result it should improve overall performance of --no-opt mode on Octane by ~1%. Bug: v8:10047 Change-Id: Ib717697cdb805c9f93286e9c62ee8a63361d3560 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965586 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66585}
-
- 20 Feb, 2020 1 commit
-
-
Dan Elphick authored
This fully tnodifies TryHasOwnProperty, TryLookupProperty, CheckPrototypeEnumCache, CheckEnumCache and ExtractFixedDoubleArrayFillingHoles. CopyElementsOnWrite is also converted except for parameters passed with ParameterMode. Also fixes the type of TryLookupProperty, which fails tests if the object parameter is actually forced to be JSReceiver. Bug: v8:10155 Change-Id: I3a925f1fd3f8a1b610d63d08a49af48ef6da505c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064979 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66373}
-
- 19 Feb, 2020 2 commits
-
-
Dan Elphick authored
This changes many functions in code-stub-assembler.h to pass or return TNode parameters rather than Node*. In general these are functions that take ParameterMode and so optionally pass IntPtrT or Smi in a Node which cannot be easily fixed so these parameters and are left alone. Also move StoreFixedArrayOrPropertyArrayElement into the private section of CodeStubAssembler's class definition. Bug: v8:10155 Change-Id: I010a928cecf105bcf9a5e9f86a402e47733ba7f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2059994 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66340}
-
Georg Neis authored
.. to improve code readability. Change-Id: I130542600bcad2a016f3dbbedab594a71cddcb9d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2061549Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66338}
-
- 17 Feb, 2020 1 commit
-
-
Jakob Kummerow authored
By replacing usage of the IsNotArrayIndex bit with IsNotIntegerIndex, we get back one bit that we can use to increase the number of hash bits stored. The price is that strings that represent array/integer indices beyond the cacheable range will have to be scanned more often, but these strings should be rare, and we expect that the additional hash bit is more worthwhile to have. Bug: v8:9904 Change-Id: I33f74b0a73f4754aee85805d4b7c409177668439 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051947Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66299}
-
- 14 Feb, 2020 1 commit
-
-
Vitaly Buka authored
This variable significantly slows down indexed-getter.html of blink_perf.bindings on linux-perf https://pinpoint-dot-chromeperf.appspot.com/job/136cce54620000 V8_STACK_UNINITIALIZED macro is the same as http://crrev.com/c/1974951 Bug: chromium:977230 Change-Id: I3e7e91804e13b856d6b2ba0a5d67f0354636c510 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046872 Commit-Queue: Vitaly Buka <vitalybuka@chromium.org> Auto-Submit: Vitaly Buka <vitalybuka@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66278}
-
- 13 Feb, 2020 1 commit
-
-
Maya Lekova authored
The GC suspect was GetAbstractPC. Fixed: v8:9990, v8:9987, chromium:1048038 Change-Id: I86a27e2098589dbf6af0808d6770c5e69987f1f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050394 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#66259}
-
- 14 Jan, 2020 1 commit
-
-
Dan Elphick authored
This Tnodifies the CombineFeedback and OverwriteFeedback methods and changes the TaggedToWord32OrBigInt* ann TaggedToNumeric methods to take TVariables. Additionally it refactors bitwise binary operators in intepreter-generator.cc and builtins-number-gen.cc and puts the common code in NumberBuiltinsAssembler. Bug: v8:10021 Change-Id: I3b15ecfadb42b50ffbfd0bd1114197e0fef42e99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995387 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#65762}
-
- 13 Jan, 2020 2 commits
-
-
Santiago Aboy Solanes authored
TNodified: * LoadValueByKeyIndex * LoadPropertyFromGlobalDictionary * LoadDetailsByKeyIndex Bug: v8:10021 Change-Id: Ie992982d0b03962658f4ef30351f1f84e8ce027e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995394Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65735}
-
Santiago Aboy Solanes authored
TNodified: * StoreObjectField * StoreObjectFieldNoWriteBarrier Bug: v8:10021 Change-Id: I74b34af410c560a1b005c0b93c71468ef57087fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993296 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65733}
-
- 10 Jan, 2020 2 commits
-
-
Santiago Aboy Solanes authored
Related ones are TryGetOwnProperty and CallGetterIfAccessor. Bug: v8:10021 Change-Id: I1b65c4260ab48b4431fa2b84a8be5789f24fa800 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993960 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#65704}
-
Seth Brenith authored
This change moves the definitions of the bitfield flags used by Symbol and Map to Torque. Symbol could directly follow the pattern established by SharedFunctionInfo, but Map required some other changes: - Until now, Torque bitfield definitions have required unsigned types. I thought that this would be the least-surprising behavior, since we never sign-extend when decoding bitfield values. However, I believe that the amount of churn involved in making ElementsKind be unsigned outweighs the benefit we were getting from this restriction (and similar difficulties are likely to arise in converting other bitfield structs to Torque), so this CL updates Torque to allow signed bitfield values. - If we try to make Map extend from all of the generated classes that define its flags, we end up with class sizing problems because some compilers only apply empty base class optimization to the first in a row of empty base classes. We could work around this issue by generating macros instead of classes, but I took this as an opportunity for a minor clean-up instead: rather than having bitfield definitions for several different bitfield structs all jumbled together in Map, they can be split up. I think this makes the code a little easier to follow, but if others disagree I'm happy to implement macro generation instead. Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65701}
-
- 09 Jan, 2020 1 commit
-
-
Jakob Kummerow authored
This CL factors out the decision-making logic whether a property key should be treated as a "property" or "element" into LookupIterator::Key, which can be constructed on its own, allowing use sites to take this distinction into account before constructing a LookupIterator from the Key, without needing to duplicate the logic. This also makes the assortment of LookupIterator constructors more uniform. Bug: chromium:1031175 Change-Id: I81d7b11ab7e4915f5c05668138e6e0c51ae11821 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962272 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65672}
-
- 07 Jan, 2020 1 commit
-
-
Dan Elphick authored
Makes the Node* versions private so they can still be called from the inlined TNode versions. Also changes to LoadFromParentFrame to return TNode<Object> since its uses don't require anything looser. Bug: v8:10021 Change-Id: I84e3831d444a7787e0b03ff2f9e665181a9caa06 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980578 Commit-Queue: Dan Elphick <delphick@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#65604}
-
- 18 Dec, 2019 1 commit
-
-
Leszek Swirski authored
This reverts commit 5377e72c. Reason for revert: Looks like the relevant graphs didn't recover after this revert, which suggests that the regression was an unrelated secondary effect. Relanding the original change since the revert did cause some microbenchmark regressions. Original change's description: > Revert "[ic] Load name/context lazily in LdaNamedProperty" > > This reverts commit 347092ac. > > Not a clean revert, since other changes got baked on top, but rather > a manual removal of LoadLazyICParameters. > > Reason for revert: Seems to actually regress bindings perf tests (see > bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't > seem to improve performance elsewhere, and increases complexity. > > Original change's description: > > [ic] Load name/context lazily in LdaNamedProperty > > > > Introduces LazyLoadICParameters which allow a LazyNode for context and > > name. These aren't used on the fast path, so we want to avoid reading > > them for both performance and register pressure reasons. > > > > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#62539} > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: chromium:981797 > Bug: chromium:982630 > Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65205} TBR=leszeks@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:981797, chromium:982630, v8:10059 Change-Id: I13754de06c83439e03e22cfaa7a14ce454076db9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973730Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65499}
-
- 27 Nov, 2019 1 commit
-
-
Leszek Swirski authored
This reverts commit 347092ac. Not a clean revert, since other changes got baked on top, but rather a manual removal of LoadLazyICParameters. Reason for revert: Seems to actually regress bindings perf tests (see bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't seem to improve performance elsewhere, and increases complexity. Original change's description: > [ic] Load name/context lazily in LdaNamedProperty > > Introduces LazyLoadICParameters which allow a LazyNode for context and > name. These aren't used on the fast path, so we want to avoid reading > them for both performance and register pressure reasons. > > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62539} # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:981797 Bug: chromium:982630 Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65205}
-
- 26 Nov, 2019 2 commits
-
-
Suraj Sharma authored
Now since we also encode KeyedAccessStoreMode information in the slow handler for some cases, the DCheck can result in failure.The Check can result in failures for other cases of StoreSlow. Removing the DCHECK altogether, now verifying the correctness of the behavior using the Kind Bits of the Handler in the method GetKeyedAccessStoreMode. Bug: chromium:1027025, chromium:1028085 Change-Id: I59acedbb499930e67ae5999d4bfd0f040a34b46e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929408Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Suraj Sharma <surshar@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65185}
-
Jakob Kummerow authored
(1) One more place in ic.cc must guard against "lookup->name()" calls when the LookupIterator might be in indexed mode. (2) Rather than burdening LookupIterator users with specifying "kGuaranteedNoTypedArray", we can do the corresponding calculation in the LookupIterator itself, which makes it robust towards any callers that haven't been updated (specifically, in Object.values). Bug: chromium:1027461,chromium:1028213 Change-Id: I76b5d08e309fc2a694955b537adbeb5a30e681f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936474Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65177}
-
- 25 Nov, 2019 1 commit
-
-
Jakob Kummerow authored
This is a reland of e1ad9b89 Original change's description: > Fixes for size_t LookupIterator > > Fixing some fallout from c968607e > aka r65078 > > Bug: chromium:1026729,chromium:1026856,chromium:1026909,chromium:1026974 > Change-Id: I98a4466595fbf1635af403ab58842977882c0453 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930907 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65158} Tbr: verwaest@chromium.org,mstarzinger@chromium.org Bug: chromium:1026729, chromium:1026856, chromium:1026909, chromium:1026974 Change-Id: I66695f05c4910c46f3c75209e14135075721f2cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932839Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65162}
-