- 27 Sep, 2019 1 commit
-
-
Mike Stanton authored
Almost everywhere, we use the ProcessedFeedback abstraction to query feedback in the compiler. The remaining exception is in handling RegExp, Object and Array literals. By bringing this in line with other feedback queries, we no longer need to serialize all feedback vector slots (possibly wasteful of memory), and offer a uniform way to pick up feedback everywhere. Bug: v8:7790, v8:9396 Change-Id: Ice42587595fe30bebfbd7835d2b2e9e49601c92e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807358 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#64016}
-
- 12 Sep, 2019 2 commits
-
-
Jakob Gruber authored
This reverts commit 4a16305b. Reason for revert: Need to revalidate assumptions behind the CHECK. Original change's description: > [compiler] Optionally apply an offset to stack checks > > The motivation behind this change is that the frame size of an optimized > function and its unoptimized version may differ, and deoptimization > may thus trigger a stack overflow. The solution implemented in this CL > is to optionally apply an offset to the stack check s.t. the check > becomes 'sp - offset > limit'. The offset is applied to stack checks at > function-entry, and is set to the difference between the optimized and > unoptimized frame size. > > A caveat: OSR may not be fully handled by this fix since we've already > passed the function-entry stack check. A possible solution would be to > *not* skip creation of function-entry stack checks for inlinees. > > This CL: 1. annotates stack check nodes with the stack check kind, where > kind is one of {function-entry,iteration-body,unknown}. 2. potentially > allocates a temporary register to store the result of the 'sp - offset' > in instruction selection (and switches input registers to 'unique' > mode). 3. Applies the offset in code generation. > > Drive-by: Add src/compiler/globals.h for compiler-specific globals. > > Bug: v8:9534,chromium:1000887 > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63701} TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9534, chromium:1000887 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63706}
-
Jakob Gruber authored
The motivation behind this change is that the frame size of an optimized function and its unoptimized version may differ, and deoptimization may thus trigger a stack overflow. The solution implemented in this CL is to optionally apply an offset to the stack check s.t. the check becomes 'sp - offset > limit'. The offset is applied to stack checks at function-entry, and is set to the difference between the optimized and unoptimized frame size. A caveat: OSR may not be fully handled by this fix since we've already passed the function-entry stack check. A possible solution would be to *not* skip creation of function-entry stack checks for inlinees. This CL: 1. annotates stack check nodes with the stack check kind, where kind is one of {function-entry,iteration-body,unknown}. 2. potentially allocates a temporary register to store the result of the 'sp - offset' in instruction selection (and switches input registers to 'unique' mode). 3. Applies the offset in code generation. Drive-by: Add src/compiler/globals.h for compiler-specific globals. Bug: v8:9534,chromium:1000887 Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63701}
-
- 06 Sep, 2019 1 commit
-
-
Swapnil Gaikwad authored
This is a reland of 8b89a7c3 Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
-
- 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}
-
- 03 Sep, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 8b89a7c3. Reason for revert: GC Stress tests timing out. See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272 Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9489 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63536}
-
Swapnil Gaikwad authored
The functionality of the GetIterator bytecode introduced previously is now extended from loading the @@iterator property to calling the property as well. This change basically absorbs the functionality of additional two bytecodes - Star, CallProperty0 in the GetIterator bytecode. Importantly, this change handles the cases of eager and lazy deoptimization in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and eager deopt of the CallProperty0 bytecode, using the continuation builtins. This mechanism can work as a template for the future bytecode that require handling such inter-bytecode deopt scenario. The tests evaluating the eager and lazy deopt scenarios are also included. Bug: v8:9489 Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63528}
-
- 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}
-
- 26 Aug, 2019 1 commit
-
-
Maya Lekova authored
This is a reland of 8ff8ddba Original change's description: > [turbofan] Further brokerize BytecodeGraphBuilder > > Replace all usages of VectorSlotPair with FeedbackSource. > > Bug: v8:7790 > Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63378} Bug: v8:7790 Change-Id: I54fbf4433a65681780fda4ded09ec2d145d36ec1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768361Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63391}
-
- 23 Aug, 2019 2 commits
-
-
Bill Budge authored
This reverts commit 8ff8ddba. Reason for revert: Causes failures on GC Stress and TSan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24138 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/27969 Original change's description: > [turbofan] Further brokerize BytecodeGraphBuilder > > Replace all usages of VectorSlotPair with FeedbackSource. > > Bug: v8:7790 > Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63378} TBR=neis@chromium.org,mslekova@chromium.org Change-Id: Ieb6fb24dd0626fd9eb2183844614ac5b3c8084e8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769287Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63387}
-
Maya Lekova authored
Replace all usages of VectorSlotPair with FeedbackSource. Bug: v8:7790 Change-Id: I0ac6e9cd8f5730154cc1842e267ca1ebfdebc874 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763536 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63378}
-
- 09 Aug, 2019 1 commit
-
-
Swapnil Gaikwad authored
This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
-
- 17 Jul, 2019 1 commit
-
-
Yang Qin authored
AIX: Changing how CallFrequency object being passed from 'by value' to 'by constant reference' to avoid copy error. GCC compile issue in AIX: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 There is a gcc compile issue in AIX: Being passed by values may occur a copy error, which can be avoided by being passed by reference. This is why the old way of CallFrequency object 'being passed by values’ has been changed to the new way of CallFrequency object 'being passed by references' to avoid this issue. Bug: v8:8193 Change-Id: I3f2e662a9ef5b641b6e978c3e91167bacc0d13d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1689027Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62788}
-
- 13 Jun, 2019 1 commit
-
-
Milad Farazmand authored
Bug: v8:8193 GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 Change-Id: Ia5ecf96ad409705e3d54fc77b081fc4907d0aa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649711Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62142}
-
- 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 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I0023200c54fa6499ae4e2cf5e4c89407cc35f187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624218Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61762}
-
- 14 May, 2019 1 commit
-
-
Georg Neis authored
This work-around got lost in the recent refactorings. Bug: v8:8193 Change-Id: I81d22e0702666d1d8ef954cd3d074e22c89378cd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#61468}
-
- 01 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: If32de05a48bddf5f746b2a3ea810ee350f6a7dda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541051 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60540}
-
- 29 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
Even though both are allowed in the style guide, it recommends to use 'using', as its syntax is more consistent with the rest of C++. This CL turns all typedefs in compiler code to 'using' declarations. R=mstarzinger@chromium.org Bug: v8:8834 Change-Id: I3baf3ecbfe2c853cb17bb479ebbf140382193b5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545896 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60527}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 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}
-
- 11 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
-
- 10 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
-
- 27 Sep, 2018 1 commit
-
-
Vasili Skurydzin authored
Bug: v8:8193 GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 Change-Id: I0d4efca4da03ef82651325e15ddf2160022bc8de Reviewed-on: https://chromium-review.googlesource.com/1228633Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56275}
-
- 25 Sep, 2018 1 commit
-
-
Creddy authored
Emit call node instead of soft-deopt for CallNoFeedback to avoid performance penalty incase one-shot code gets optimized. Tweek the inling heuristic to avoid recurisve inling with stress-opt. Bug: v8:8106, v8:8072 Change-Id: I09643c0648b6c880f491d08a8a73f1960ca999c0 Reviewed-on: https://chromium-review.googlesource.com/1239075Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Chandan Reddy <chandanreddy@google.com> Cr-Commit-Position: refs/heads/master@{#56200}
-
- 21 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
The JSToInteger operator is not used anywhere in TurboFan nowadays, so no point in keeping the dead code in the tree. Bug: v8:8015 Change-Id: If03ba63c4b932ba0aac60b9bbc89fee3909a93c6 Reviewed-on: https://chromium-review.googlesource.com/1238238Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56126}
-
- 05 Sep, 2018 1 commit
-
-
Hai Dang authored
This is a reland of 1c48d52b. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
-
- 31 Aug, 2018 1 commit
-
-
Georg Neis authored
This reverts commit 1c48d52b. Reason for revert: Clusterfuzz found something. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
-
- 30 Aug, 2018 1 commit
-
-
Hai Dang authored
This CL improves the performance of creating [...a, b] or [...a]. If the array literal has a leading spread, this CL emits the bytecode [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable is implemented by [IterableToListDefault] builtin to create the initial array for the leading spread. IterableToListDefault has a fast path to clone efficiently if the spread is an actual array. The bytecode generated is now shorter. Bytecode generation is refactored into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit from this optimization also. For now, turbofan also lowers the bytecode to the builtin. The idiomatic use of [...a] to clone the array a now performs better than a simple for-loop, but still does not match the performance of slice. Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#55520}
-
- 02 Aug, 2018 1 commit
-
-
Georg Neis authored
R=sigurds@chromium.org Change-Id: I9d07847ef92ff7a512c1624b492b37b6991e3c56 Reviewed-on: https://chromium-review.googlesource.com/1160304Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#54867}
-
- 23 Jul, 2018 1 commit
-
-
Sigurd Schneider authored
This is a reland of 9eca23e9 Adds a deopt continuation, which fixes JavaScript stack traces to contain the number constructor after inlining. Original change's description: > [turbofan] Inline Number constructor in certain cases > > This CL adds inlining for the Number constructor if new.target is not > present. The lowering is BigInt compatible, i.e. it converts BigInts to > numbers. > > Bug: v8:7904 > Change-Id: If03b9f872d82e50b6ded7709069181c33dc44e82 > Reviewed-on: https://chromium-review.googlesource.com/1118557 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#54454} Bug: v8:7904 Change-Id: Ic416e5ba81fa3a0f59ae4afa80df83c46a759487 Reviewed-on: https://chromium-review.googlesource.com/1146581 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#54609}
-
- 20 Jul, 2018 1 commit
-
-
Caitlin Potter authored
As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
-
- 19 Jul, 2018 1 commit
-
-
Sigurd Schneider authored
This reverts commit 9eca23e9. Reason for revert: Clusterfuzz correctness issue Original change's description: > [turbofan] Inline Number constructor in certain cases > > This CL adds inlining for the Number constructor if new.target is not > present. The lowering is BigInt compatible, i.e. it converts BigInts to > numbers. > > Bug: v8:7904 > Change-Id: If03b9f872d82e50b6ded7709069181c33dc44e82 > Reviewed-on: https://chromium-review.googlesource.com/1118557 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#54454} TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7904 Change-Id: Ie5fa6c1262b8acc33edb672a0124f4458fcded86 Reviewed-on: https://chromium-review.googlesource.com/1142777Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#54544}
-
- 16 Jul, 2018 1 commit
-
-
Sigurd Schneider authored
This CL adds inlining for the Number constructor if new.target is not present. The lowering is BigInt compatible, i.e. it converts BigInts to numbers. Bug: v8:7904 Change-Id: If03b9f872d82e50b6ded7709069181c33dc44e82 Reviewed-on: https://chromium-review.googlesource.com/1118557 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54454}
-
- 05 Jul, 2018 1 commit
-
-
Creddy authored
* Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
-
- 11 Jun, 2018 1 commit
-
-
Sigurd Schneider authored
This CL adds a TFS stub for RegExp#test and moves several checks to the JSCallReducer. In particular, the JSCallReducer checks that - property {exec} on the regexp is still the original exec - property {lastIndex} on the regexp is a non-negative smi The stub does not repeat these checks in release mode. This effectively means that if the regexp is known, we can perform these checks at compile time, and get away with a map dependency. Bug: v8:7779, v8:7200 Change-Id: I0c6d711d4f1d2f6f325a1c02855b0e1b62e014c8 Reviewed-on: https://chromium-review.googlesource.com/1074654 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53630}
-
- 24 May, 2018 1 commit
-
-
Jaroslav Sevcik authored
Currently, we context allocate all parameters for generators. With this CL, we keep arguments on stack (unless they escape to inner closure) and copy them between the stack and the generator's register file on suspend/resume. This will save context allocation in most cases. Note: There is an asymmetry between suspend and resume. - Suspend copies arguments and registers to the generator. - Resume copies only the registers from the generator, the arguments are copied by the ResumeGenerator trampoline. Bug: v8:5164 Change-Id: I6333898c60abf461b1ab1b5c6d3dc7188fa95649 Reviewed-on: https://chromium-review.googlesource.com/1063712 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53327}
-
- 04 May, 2018 1 commit
-
-
Toon Verwaest authored
Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
-