- 08 Apr, 2020 1 commit
-
-
Mythri A authored
For keyed stores we recompute handlers when we see a new map so that we could transition to the most general elements kind we have seen so far. When recomputing these handlers we drop the deprecated maps. Instead we could TryUpdate deprecated maps. This would be inline with what TurboFan does and also may be better for performance. Bug: chromium:1053939 Change-Id: Id38b60538d56f4b376460c0faece20768a18f25f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2130129 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67060}
-
- 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}
-
- 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}
-
- 03 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Add the remaining missing templatizations to allow an initial wiring in of the off-thread factory into streaming compilation finalization. The off-thread finalization is behind a flag, disabled by default: --finalize-streaming-on-background When the flag is enabled, background tasks will perform perform the finalization during their background execution, and will release the parser and compilation jobs once they are no longer needed. The implementation is complete enough for performance testing, but not enough for launch. Notably, there is no support for: * Class boilerplates (the code is marked unreachable), * Exceptions during finalization, i.e. parse/compile warnings/errors, * Allocation sampling, * Logging, * Asm.js, * Parallel complication tasks * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()") This patch also adds some tracing events for the various stages of the off-thread finalization (including the main-thread merge) for further performance improvements. Bug: chromium:1011762 Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66566}
-
- 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}
-
- 27 Nov, 2019 1 commit
-
-
Leszek Swirski authored
To indicate that the Isolate* in getters might not be a "real" isolate, but rather a calculated one from GetIsolateForPtrCompr only used for calculating the isolate root, make that function return a const Isolate* and change field getters, Object::IsFoo predicates, and related functions to all take a const Isolate* instead of an Isolate* With this change, we can slightly more confidently use Objects that are in OffThreadSpace, without having to worry too much about having an Isolate* floating around that could accidentally be used. This is a slight abuse of const semantics, but it allows implicit conversion from Isolate* arguments to the const Isolate* parameter. Bug: v8:7703 Bug: chromium:1011762 Change-Id: I54d4a65d2299477195f4d754cabe64ce34fdaa4c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939455 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65199}
-
- 21 Nov, 2019 1 commit
-
-
Tobias Tebbi authored
This introduces a new keyword "shape" in addition to "class", which allows the definition of a type that extends a JSObject subclass and specifies one or several maps with statically known in-object properties. Differences compared to normal classes: - Shapes are transient since they specify maps instead of instance types. - Shapes have a known size. - Fields of shapes are always in-object properties. In particular, this means that their offset is after kHeaderSize. - It's forbidden to inherited from shapes. - Since shapes usually specify NativeContext-dependent maps, it's not possible to write runtime type-checks for them. Thus this CL avoids mapping them to their own TNode type, as the CAST macro won't work properly. We had runtime-checks for some of them nevertheless, some of them scarily confusing like IsJSSloppyArgumentsObject, that actually just checked the instance type. Drive-by cleanups and simplifications: - Allow subclassing from non-abstract classes and remove @dirtyInstantiatedAbstractClass. This attribute stems from a mis- conception of how instance types work, and with this change it ceases to have semantic influence. - Replace the existing JSArgumentsObject subclasses into two shapes. JSArgumentsObjectWithLength had to be removed since shapes don't support subclassing. - Place kHeaderSize correctly for objects with indexed fields. Design doc: https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU Bug: v8:8944 Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65108}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 10 Oct, 2019 1 commit
-
-
Suraj Sharma authored
Bug: v8:9779 Change-Id: I8603942e91b7e03fc9feaa69a8716ffffcf969b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1851504Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Suraj Sharma <surshar@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64218}
-
- 08 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
This is useful for the upcoming "huge TypedArrays" support, to be able to quickly decide in stubs/generated code whether a string used as the key for a property load/store can possibly be an exotic integer index. Bug: v8:4153 Change-Id: I50ce655d2f78fb36e5615fd580f22c9290216c84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1821460 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#64165}
-
- 02 Oct, 2019 1 commit
-
-
Mythri A authored
Premonomorphic state was only used for store globals to handle contextual store on a global object [1]. We now handle these differently and we move to fast handlers even without going through premonomorphic state after this cl: https://chromium-review.googlesource.com/c/v8/v8/+/1807356. Also, with lazy feedback this would be a relatively uncommon case anyway. So, we no longer need premonomorphic state. This cl removes this state entirely. [1]: https://bugs.chromium.org/p/v8/issues/detail?id=8712 Bug: v8:8394 Change-Id: I71fb918b82b0c321a9705e32c8fc44e9ec223b38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1833690Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#64085}
-
- 04 Sep, 2019 1 commit
-
-
Tobias Tebbi authored
This reverts commit 352a154e. Reason for revert: https://crbug.com/999972 Original change's description: > [compiler] improve inlining heuristics: call frequency per executed bytecodes > > TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan > compile time including off-thread, while improving Octane scores by ~2%. > > How things used to work: > > There is a flag FLAG_min_inlining_frequency that limits inlining by > the callsite being sufficiently frequently executed. This call frequency > was measured relative to invocations of the parent (= the function we > originally optimize). At the same time, the limit was very low (0.15), > meaning we mostly relied on the total amount of inlined code > (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining. > > How things work now: > > Instead of measuring call frequency relative to parent invocations, we > should have a measure that predicts how often the callsite in question > will be executed in the future. An obvious attempt at that would be to > measure how often the callsite was executed in absolute numbers in the > past. But depending on how fast feedback stabilizes, it can take more > or less time until we optimize a function. If we just take the absolute > call frequency up to the point in time when we optimize, we would > inline more for functions that stabilize slowly, which doesn't make > sense. So instead, we measure absolute call count per KB of executed > bytecodes of the parent function. > Since inlining big functions is more expensive, this threshold is > additionally scaled linearly with the bytecode-size of the inlinee. > The resulting formula is: > call_frequency > > FLAG_min_inlining_frequency * > (bytecode.length() - FLAG_max_inlined_bytecode_size_small) / > (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small) > > The new threshold is chosen in a way that it effectively limits > inlining, which allows us to increase > FLAG_max_inlined_bytecode_size_cumulative without increasing inlining > in general. > > The reduction in compile time (x64 build) of ~10% was observed in Octane, > ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark. > The hope is that this will reduce CPU-time in real-world situations > too. > The Octane improvements come from inlining more in places where it > matters. > > Bug: v8:6682 > > Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63449} TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6682 chromium:999972 Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63554}
-
- 29 Aug, 2019 1 commit
-
-
Tobias Tebbi authored
TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan compile time including off-thread, while improving Octane scores by ~2%. How things used to work: There is a flag FLAG_min_inlining_frequency that limits inlining by the callsite being sufficiently frequently executed. This call frequency was measured relative to invocations of the parent (= the function we originally optimize). At the same time, the limit was very low (0.15), meaning we mostly relied on the total amount of inlined code (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining. How things work now: Instead of measuring call frequency relative to parent invocations, we should have a measure that predicts how often the callsite in question will be executed in the future. An obvious attempt at that would be to measure how often the callsite was executed in absolute numbers in the past. But depending on how fast feedback stabilizes, it can take more or less time until we optimize a function. If we just take the absolute call frequency up to the point in time when we optimize, we would inline more for functions that stabilize slowly, which doesn't make sense. So instead, we measure absolute call count per KB of executed bytecodes of the parent function. Since inlining big functions is more expensive, this threshold is additionally scaled linearly with the bytecode-size of the inlinee. The resulting formula is: call_frequency > FLAG_min_inlining_frequency * (bytecode.length() - FLAG_max_inlined_bytecode_size_small) / (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small) The new threshold is chosen in a way that it effectively limits inlining, which allows us to increase FLAG_max_inlined_bytecode_size_cumulative without increasing inlining in general. The reduction in compile time (x64 build) of ~10% was observed in Octane, ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark. The hope is that this will reduce CPU-time in real-world situations too. The Octane improvements come from inlining more in places where it matters. Bug: v8:6682 Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63449}
-
- 08 Jul, 2019 2 commits
-
-
Clemens Hammacher authored
Cpplint usually checks for non-const reference arguments. They are forbidden in the style guide, and v8 does not explicitly make an exception here. This CL re-enables that warning, and fixes all current violations by adding an explicit "NOLINT(runtime/references)" comment. In follow-up CLs, we should aim to remove as many of them as possible. TBR=mlippautz@chromium.org Bug: v8:9429 Change-Id: If7054d0b366138b731972ed5d4e304b5ac8423bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687891Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62551}
-
Nico Hartmann authored
Feedback shall not be updated by the deoptimizer. Although this mechanism exists, it shall not be used if possible. This CL changes how V8 learns from BigInt deopts: Previously we updated feedback on the BinaryOperations in the deoptimizer, now we let the interpreter widen the feedback type from BigInt to Any after the deopt has occurred. Bug: v8:9407 Change-Id: I92e5e733085b433fd8ab452674d02404b81b2796 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687419Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62548}
-
- 26 Jun, 2019 2 commits
-
-
Igor Sheludko authored
Bug: v8:9353 Change-Id: I740b2987da1719af6c3d4a6471e7f047801cfd5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678368Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62391}
-
Nico Hartmann authored
This is a reland of 5ff38bae Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} Bug: v8:9213 Change-Id: Ic0caf7aab2103b8f5e22a504427e8604cc894d75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677209Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62381}
-
- 25 Jun, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 5ff38bae. Reason for revert: flaky test that is not normally flaky failed. See: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap%20-%20debug/24531 Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,nicohartmann@google.com Change-Id: I5ae63a0183283894b6d1130792ab37a95b014550 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9213 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676607Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#62364}
-
Nico Hartmann authored
This CL introduces the necessary infrastructure to generate speculative BigInt operations in case of BigInt feedback. In particular, the JSAdd operator is lowered to a speculative call to the BigIntAdd builtin, with a deopt bailout in case of exceptions or violated assumptions. Bug: v8:9213 Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62362}
-
- 31 May, 2019 1 commit
-
-
Benedikt Meurer authored
This fixes a problem where ICs for transitioning stores go MEGAMORPHIC if the transition target map dies in between invocations of the IC, which is totally possible, since we only hold on weakly to these transition targets (both from the FeedbackVectors and also from the TransitonArrays). The root problem here was an inconsistency in how the maps and handlers are being reported by the FeedbackVector. On the on hand side the method FeedbackVector::ExtractMaps() will report all receiver maps that are still present (i.e. which haven't died themselves), but then the other method FeedbackVector::FindHandlers() will only report handlers that are still alive (i.e. which in case of transition target maps being used as handlers haven't died yet). If the length of these lists don't match the IC chickens out and goes MEGAMORPHIC. But this is exactly the case with the transitioning stores, where there's no handler anymore, i.e. as can be seen in this simple example: ``` // Flags: --expose-gc function C() { this.x = 1; } new C(); new C(); gc(); // map with the `C.x` property dies new C(); // now the STORE_IC in C goes MEGAMORPHIC ``` So the problem is that we have these two methods that don't agree with each other. Now FeedbackVector::ExtractMaps() is also used by TurboFan and it even reports receiver maps for PREMONOMORPHIC state, which is different from the use case that the ICs need. So I replaced the FeedbackVector::FindHandlers() with a completely new method FeedbackVector::ExtractMapsAndHandlers(), which returns both the maps and handlers, exactly as the ICs need it. And only returns pairs for which both the receiver map and the handler are still alive. This fixes the odd problem that sometimes STORE_ICs going MEGAMORPHIC for no apparent reason. Due to the weakness of the transition target maps, they can still die and cause deoptimizations, but at least TurboFan will now be able to reoptimize again later with the new maps and still generate proper code. Bug: v8:9316 Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Change-Id: I74c8b60f792f310dc813f997e69efe9ad434296a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637878 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61948}
-
- 27 May, 2019 1 commit
-
-
Clemens Hammacher authored
This replaces all typedefs that define types and not functions by the equivalent "using" declaration. This was done mostly automatically using this command: ag -l '\btypedef\b' src test | xargs -L1 \ perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg' Patchset 2 then adds some manual changes for typedefs for pointer types, where the regular expression did not match. R=mstarzinger@chromium.org TBR=yangguo@chromium.org, jarin@chromium.org Bug: v8:9183 Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61849}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 3 commits
-
-
Jaroslav Sevcik authored
Unfortunately, we still have to keep the field because GC mole and Torque do not support platform specific padding well (see http://crbug.com/v8/9287). Bug: v8:9183 Change-Id: I2210be4b8174c97bc82145605f9b862aac3bdc37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624791Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61802}
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
Clemens Hammacher authored
This CL was generated by an automatic clang AST rewriter using this matcher expression: callExpr( callee( cxxMethodDecl( hasName("operator->"), ofClass(isSameOrDerivedFrom("v8::internal::Object")) ) ), argumentCountIs(1) ) The "->" at the expression location was then rewritten to ".". R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org Bug: v8:9183, v8:3770 No-Try: true No-Tree-Checks: true Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61764}
-
- 20 May, 2019 3 commits
-
-
Jaroslav Sevcik authored
This reverts commit ad1fcd43. Reason for revert: Breaks waterfall. Original change's description: > [cleanup] Remove the now-unused deopt_count from feedback vector. > > Bug: v8:9183 > Change-Id: Iceeccc8ab1e4e77b428e7e2feec39bff3317f241 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617675 > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61665} TBR=mstarzinger@chromium.org,jarin@chromium.org Change-Id: Iea0e6a329f55a3a941f0b976925b2abdf7eece38 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9183 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619867Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61666}
-
Jaroslav Sevcik authored
Bug: v8:9183 Change-Id: Iceeccc8ab1e4e77b428e7e2feec39bff3317f241 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617675 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61665}
-
Yang Guo authored
Code that is being moved primarily deal with layout of a JSObject, accessing properties and elements, and map transitions. NOTREECHECKS=true NOTRY=true Bug: v8:9247 Change-Id: Ibce5d5926ac4021c8d40c4dd109948775ce1da58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613994 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61638}
-
- 25 Apr, 2019 1 commit
-
-
Irina Yatsenko authored
AllocationMemento, CoverageInfo, DebugInfo, DescriptorArray, FeedbackCell, FeedbackVector Bug: v8:8952 Change-Id: I17297706a8d9bd4a0ee01b0b133ca613dbc31cf9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1521910 Commit-Queue: Irina Yatsenko <irinayat@microsoft.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61026}
-
- 10 Apr, 2019 3 commits
-
-
Mythri A authored
This is a reland of Ie3ac389e1c082d1671efd4d74abc076ce943301b with a fix for MSAN failures. Interrupt budget was store in bytecode array and used to be shared across all contexts. With lazy feedback allocation, using context independent interrupt budget might lead to performance cliffs when we have closures that do not share the same feedback (for ex: across contexts). This would be a problem even earlier but it could be more pronounced with feedback vector allocation, since the budgets for optimization is much higher (144x) than the budget for feedback allocation. Bug: chromium:948835, v8:8394 Change-Id: I74f998c30e27caf3bd34510f4d7f57b65e6c7f0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561072Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#60750}
-
Michael Achenbach authored
This reverts commit f3994485. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/26128 Original change's description: > [interpreter] Move interrupt budget from BytecodeArray to FeedbackCell > > Interrupt budget was store in bytecode array and used to be shared > across all contexts. With lazy feedback allocation, using context > independent interrupt budget might lead to performance cliffs when > we have closures that do not share the same feedback (for ex: across > contexts). This would be a problem even earlier but it could be > more pronounced with feedback vector allocation, since the budgets > for optimization is much higher (144x) than the budget for feedback > allocation. > > Bug: chromium:948835, v8:8394 > Change-Id: Ie3ac389e1c082d1671efd4d74abc076ce943301b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1558088 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60734} TBR=jarin@chromium.org,mlippautz@chromium.org,mythria@chromium.org,jgruber@chromium.org,bmeurer@chromium.org Change-Id: Icbec4d28d6ac258827e222461cff51f2a2f42472 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:948835, v8:8394 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560990Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#60735}
-
Mythri A authored
Interrupt budget was store in bytecode array and used to be shared across all contexts. With lazy feedback allocation, using context independent interrupt budget might lead to performance cliffs when we have closures that do not share the same feedback (for ex: across contexts). This would be a problem even earlier but it could be more pronounced with feedback vector allocation, since the budgets for optimization is much higher (144x) than the budget for feedback allocation. Bug: chromium:948835, v8:8394 Change-Id: Ie3ac389e1c082d1671efd4d74abc076ce943301b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1558088 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#60734}
-
- 04 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: Ie624a02598f5c3a43e40e03d0337c17ca5cc3769 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541052 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#60628}
-
- 25 Mar, 2019 2 commits
-
-
Mythri authored
Allocate feedback vectors lazily when the function's interrupt budget has reached a specified threshold. This cl introduces a new field in the ClosureFeedbackCellArray to track the interrupt budget for allocating feedback vectors. Using the interrupt budget on the bytecode array could cause problems when there are closures across native contexts and we may delay allocating feedback vectors in one of them causing unexpected performance cliffs. In the long term we may want to remove interrupt budget from bytecode array and use context specific budget for tiering up decisions as well. Bug: v8:8394 Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#60450}
-
Benedikt Meurer authored
The --type_info_threshold is no longer supported for a long time and doesn't do anything useful nowadays, so no point in having that around. Drive-by-fix: Remove the FeedbackVector::ComputeCounts() logic, since it's dead code anyways by now. Bug: v8:8834 Change-Id: I05f7517b3b82e34c0a83357337a456ab9c9f1f42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538128 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60442}
-
- 12 Mar, 2019 1 commit
-
-
Mythri authored
We want to allocate feedback vectors lazily in lite mode. To do that, we should create closures with the correct feedback cell. This cl allocates feedback cell arrays to hold these feedback cells in lite mode. This cl also modifies the compile lazy to builtin to expect these arrays in the feedback cell. Drive-by fix: InterpreterEntryTrampoline no longer has argument count in a register. So updated comments and removed unnecessary push/pop of this register. Bug: v8:8394 Change-Id: I10d8ca67cebce61a284f0c80b200e1f0c24577a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511274Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#60189}
-
- 11 Mar, 2019 1 commit
-
-
Mythri authored
This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
-
- 01 Mar, 2019 1 commit
-
-
Matt Gardner authored
The original was reverted for breaking webkit layout tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270 It also caused the following clusterfuzz failures: chromium:935832 This was a correctness bug due to not properly handling the case of arrays with prototypes other than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect both in access-assembler and in Turbofan. chromium:935932 This bug was that there was no handling for Has checks on the global object. Turbofan was emitting code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in debug builds but in release could show up in different places. This is the bug that caused the webkit layout test failure that led to the revert. Both bugs are fixed by in CL, and tests are added for those cases. Bug: v8:8733, chromium:935932, chromium:935832 Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925 Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59958}
-
- 26 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
This reverts commit 32fc0acf. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270 layout test breakage: https://test-results.appspot.com/data/layout_results/V8-Blink_Linux_64/30270/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html There is a dead node arriving in representation selection, which might indicate that the problem is not in this CL, but that this CL stirs up the node soup in such a way that dead code elimination gets confused. Original change's description: > Optimize `in` operator > > This change implements optimizations for the `in` operator for packed array > elements and object properties. It adds a new feedback slot kind and an IC > path similar to KeyedLoadIC for handling the lookups. TurboFan uses the > feedback to optimize based on the maps and keys. > > For more details see: > https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig > > This can provide 10x performance improvements of on loops of the form: > > for (let i = 0; i < ary.length; ++i) { > if (i in ary) { > ... > } > } > > > Bug: v8:8733 > Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8 > Reviewed-on: https://chromium-review.googlesource.com/c/1432598 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Matt Gardner <magardn@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#59843} TBR=ulan@chromium.org,rmcilroy@chromium.org,jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org,bmeurer@chromium.org,verwaest@chromium.org,magardn@microsoft.com Change-Id: Ib2db974e5bed4c4a2b6b450f796bdc4b0b8fd562 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8733 Reviewed-on: https://chromium-review.googlesource.com/c/1488761Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59857}
-
- 25 Feb, 2019 1 commit
-
-
Matt Gardner authored
This change implements optimizations for the `in` operator for packed array elements and object properties. It adds a new feedback slot kind and an IC path similar to KeyedLoadIC for handling the lookups. TurboFan uses the feedback to optimize based on the maps and keys. For more details see: https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig This can provide 10x performance improvements of on loops of the form: for (let i = 0; i < ary.length; ++i) { if (i in ary) { ... } } Bug: v8:8733 Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8 Reviewed-on: https://chromium-review.googlesource.com/c/1432598Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59843}
-