- 20 Mar, 2020 2 commits
-
-
Santiago Aboy Solanes authored
Now that it is implicit in function entry and loop iteration, there is no need for an explicit bytecode. Also updated tests that used explicit bytecodes. Bug: v8:10149, v8:9960 Change-Id: I3ca582f276829bd54feb35e6d4ea656a32efbd54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093507Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66811}
-
Santiago Aboy Solanes authored
Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. Bug: v8:10149, v8:9960 Fixes: v8:10149 Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66809}
-
- 10 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
-
- 22 Jan, 2020 1 commit
-
-
Georg Neis authored
... and consult it there from the various reducers. The flag makes no sense without the broker and the reducers already have access to the broker, so we can avoid an additional flag per reducer. Bug: v8:7790 Change-Id: I448050a55951b94d5313c1a79a502be906b98b25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013108 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65918}
-
- 09 Jan, 2020 1 commit
-
-
Maya Lekova authored
Bug: v8:7790 Change-Id: Idf066adcd5c3dca3004e2eaa0d8fa389755720af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991490Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65671}
-
- 13 Dec, 2019 1 commit
-
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: Ibd6790a222590fd4dce9f918219a19f01c2e1e0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960293Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65439}
-
- 06 Nov, 2019 1 commit
-
-
Victor Gomes authored
The bug is due to an unexpected opcode. To avoid similar issues in the future, we fallback to CheckContextExtensionSlowPath. This was the default behaviour before the CL (https://chromium-review.googlesource.com/c/v8/v8/+/1876051). Bug: chromium:1020983 Change-Id: Ia7f0f2986ec0008d1128ad3856efbb5d9e52dfc6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899989 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64794}
-
- 04 Nov, 2019 1 commit
-
-
Nico Hartmann authored
Changing the target of JSCall nodes (e.g. while lowering higher order calls) now preserves feedback and speculation mode to allow further (speculative) optimizations. A flag is introduced to mark feedback unrelated to the call target after such a transformation. This flag is used to prevent access to the feedback without the need to invalidate it. Bug: v8:9702 Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64733}
-
- 31 Oct, 2019 1 commit
-
-
Maya Lekova authored
Implement the possibility to revisit the same function in the serializer using equality of its arguments. Bug: v8:7790 Change-Id: I609a6009bf503e378e50d0b32c6f1c13721d2557 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863198 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64683}
-
- 30 Oct, 2019 1 commit
-
-
Jakob Gruber authored
This is a reland of 4a16305b The original CL adjust only one part of the stack check, namely the comparison of the stack pointer against the stack limit in generated code. There is a second part: Runtime::kStackGuard repeats this check to distinguish between a stack overflow and an interrupt request. This second part in runtime must apply the offset just like in generated code. It is implemented in this reland by the StackCheckOffset operator and a new StackGuardWithGap runtime function. 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} Bug: v8:9534, chromium:1000887 Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64634}
-
- 29 Oct, 2019 1 commit
-
-
Victor Gomes authored
ClusterFuzzer found that a context can be created by a call to the runtime when checking for context extensions on the bytecode graph builder. That happens in large contexts. Bug: chromium:1019069 Change-Id: I7ab66dceedd56476ab972d7998ef4ca6896dc868 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886691Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#64605}
-
- 28 Oct, 2019 1 commit
-
-
Victor Gomes authored
We know statically if a context has an extension slot or not, but that was dynamically checked. The CL lifts the ScopeInfo chain to the compiler and does the check statically, it only generates the undefined check if the context has an extension slot. Bug: v8:9744 Change-Id: I169d05bb11b36501e97af00d30ae44bedcd6be83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876051 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#64599}
-
- 22 Oct, 2019 3 commits
-
-
Victor Gomes authored
Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
-
Clemens Backes authored
This reverts commit 392a1217. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d4 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
-
Victor Gomes authored
This is a reland of c48096d4 Original change's description: > Reland "[runtime] Remove extension slots from context objects" > > This is a reland of c07c02e1 > > Original change's description: > > [runtime] Remove extension slots from context objects > > > > Context objects have an extension slot, which contains further > > additional data that depends on the type of the context. > > > > This CL removes the extension slot from contexts that don't need > > them, hence reducing memory. > > > > The following contexts will still have an extension slot: native, > > module, await, block and with contexts. See objects/contexts.h for > > what the slot is used for. > > The following contexts will not have an extension slot anymore (they > > were not used before): script, catch and builtin contexts. > > Eval and function contexts only have the extension slot if they > > contain a sloppy eval. > > > > Bug: v8:9744 > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64372} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64380} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Victor Gomes <victorgomes@google.com> Cr-Commit-Position: refs/heads/master@{#64451}
-
- 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}
-
- 10 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
Since we switched to C++14 now, we can use {std::make_unique} instead of our own {base::make_unique} from {template-utils.h}. R=mstarzinger@chromium.org, yangguo@chromium.org Bug: v8:9687 No-Try: true Change-Id: I660eb30038bbb079cee93c7861cd87ccd134f01b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789300 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63642}
-
- 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 2 commits
-
-
Georg Neis authored
This is a reland of ab089c78, after making a flaky test more robust. Original change's description: > [turbofan] Prepare for moving part of CreateGraph into the background > > - Pass Refs, not Handles, to graph builder, and drop bytecode array argument > (get it from SFI instead). > - Add some fields to FeedbackVectorRef that are needed to avoid heap access > in BytecodeGraphBuilderPhase. > - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more > than just the feedback slots. > - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such > that CreateGraph is last. > > Bug: v8:7790 > Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63515} Bug: v8:7790 Change-Id: Ia6f4c1ebd82dea93c14437514d0e25b730523f75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781694Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63545}
-
Georg Neis authored
Change-Id: I65c1c5a75cde738f8fce33d2230fd12338f55154 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783000Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63540}
-
- 03 Sep, 2019 4 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}
-
Leszek Swirski authored
This reverts commit ab089c78. Reason for revert: Breaking GC stress (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/27523) Original change's description: > [turbofan] Prepare for moving part of CreateGraph into the background > > - Pass Refs, not Handles, to graph builder, and drop bytecode array argument > (get it from SFI instead). > - Add some fields to FeedbackVectorRef that are needed to avoid heap access > in BytecodeGraphBuilderPhase. > - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more > than just the feedback slots. > - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such > that CreateGraph is last. > > Bug: v8:7790 > Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63515} TBR=neis@chromium.org,mslekova@chromium.org Change-Id: I4dc95907657597d12cbe1ce6a8ebb694ef44e915 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781687Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63517}
-
Georg Neis authored
- Pass Refs, not Handles, to graph builder, and drop bytecode array argument (get it from SFI instead). - Add some fields to FeedbackVectorRef that are needed to avoid heap access in BytecodeGraphBuilderPhase. - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more than just the feedback slots. - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such that CreateGraph is last. Bug: v8:7790 Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63515}
-
- 02 Sep, 2019 1 commit
-
-
Maya Lekova authored
Bug: v8:7790 Change-Id: I79b81d66751707756139db50720080a144bdcd38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781045 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63506}
-
- 30 Aug, 2019 2 commits
-
-
Maya Lekova authored
Introduce JSGlobalObjectRef to the heap broker. Bug: v8:7790 Change-Id: I055a0545b582d6ff4c4e0dd639ce532311a76fec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773267Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63472}
-
Maya Lekova authored
BytecodeGraphBuilder is now completely heap-access free. Bug: v8:7790 Change-Id: I86a26550cb65015a804dbabf117e11d2bc6aff60 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773255 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63470}
-
- 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}
-
- 20 Aug, 2019 1 commit
-
-
Georg Neis authored
... at graph building time already, just like we do for other property accesses. Bug: v8:7790 Change-Id: I7ffc8ee4fb1df91fc59271edd7b70c14f531330a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762018Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63278}
-
- 19 Aug, 2019 3 commits
-
-
Georg Neis authored
This is a reland of 29585a06 after removing an incorrect DCHECK. Original change's description: > [turbofan] Various serializer/broker improvements > > They are all somewhat entangled, sorry for the big CL. > > - Brokerize remaining feedback vector slots. > - Introduce Hints::SingleConstant helper. > - Introduce SerializationPolicy enum. > - Eliminate use of nullptr for megamorphic load/store ic feedback. > Instead use the corresponding ProcessedFeedback with an empty list > of maps or the like. new class MegamorphicFeedback. > - Separate processing of feedback from serialization. This eliminates > code duplication. > - Be very careful when clearing hints not to overwrite hints that are > being processed. > - Move AccessInfos out of NamedAccessFeedback. Always store them in > property_access_infos_ map on broker. (This was actually unused > before, somewhat by mistake.) > - Support map inference in concurrent inlining. Rewrite > ElementAccessFeedback such that we can refine it with the set of > inferred maps. > > TBR: mvstanton@chromium.org > Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63232} TBR: mvstanton@chromium.org Bug: v8:7790 Change-Id: Ia4acd31b339a941ee065e1ae4835bb7b85d5685e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758319Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63241}
-
Maya Lekova authored
This reverts commit 29585a06. Reason for revert: Breaks GC stress bots - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24009 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/27281 Original change's description: > [turbofan] Various serializer/broker improvements > > They are all somewhat entangled, sorry for the big CL. > > - Brokerize remaining feedback vector slots. > - Introduce Hints::SingleConstant helper. > - Introduce SerializationPolicy enum. > - Eliminate use of nullptr for megamorphic load/store ic feedback. > Instead use the corresponding ProcessedFeedback with an empty list > of maps or the like. new class MegamorphicFeedback. > - Separate processing of feedback from serialization. This eliminates > code duplication. > - Be very careful when clearing hints not to overwrite hints that are > being processed. > - Move AccessInfos out of NamedAccessFeedback. Always store them in > property_access_infos_ map on broker. (This was actually unused > before, somewhat by mistake.) > - Support map inference in concurrent inlining. Rewrite > ElementAccessFeedback such that we can refine it with the set of > inferred maps. > > TBR: mvstanton@chromium.org > Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63232} TBR=mvstanton@chromium.org,neis@chromium.org Change-Id: I88625d92fddf993db63661666c59af05a47b2b58 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758314Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63237}
-
Georg Neis authored
They are all somewhat entangled, sorry for the big CL. - Brokerize remaining feedback vector slots. - Introduce Hints::SingleConstant helper. - Introduce SerializationPolicy enum. - Eliminate use of nullptr for megamorphic load/store ic feedback. Instead use the corresponding ProcessedFeedback with an empty list of maps or the like. new class MegamorphicFeedback. - Separate processing of feedback from serialization. This eliminates code duplication. - Be very careful when clearing hints not to overwrite hints that are being processed. - Move AccessInfos out of NamedAccessFeedback. Always store them in property_access_infos_ map on broker. (This was actually unused before, somewhat by mistake.) - Support map inference in concurrent inlining. Rewrite ElementAccessFeedback such that we can refine it with the set of inferred maps. TBR: mvstanton@chromium.org Change-Id: I05e9eb250bdffc6dff29db01742550a86a41cb31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752853 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63232}
-
- 16 Aug, 2019 1 commit
-
-
Mike Stanton authored
GetIterator currently acts as a property load of the iterator symbol (soon it will also call it). It makes sense to apply the same early lowering logic as we do for property loads in the bytecode graph builder. This also brings our treatment of the bytecode in-line with the way it's treated in the serializer, which already respects the early-lowering semantics. Bug: v8:7790 Change-Id: Ieadc4b307b9f6d9a5aa77ca10c7c818026776f33 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758304 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63224}
-
- 12 Aug, 2019 2 commits
-
-
Mike Stanton authored
The BytecodeGraphBuilder still looks at the heap. This CL mostly eliminates heap lookups for: * CreateArrayLiteral * CreateObjectLiteral * CreateRegExpLiteral What remains is the lookup embedded in the creation of a VectorSlotPair, which will be addressed in a subsequent change. Bug: v8:7790 Change-Id: I5e4167f5542b84ed3684ad61f3dd1ef8ad84c96b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745482 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63173}
-
Mike Stanton authored
This CL eliminates managed heap reads from the ByteCodeGraphBuilder from constants. These reads and serializations are made at serialization time. Bug: v8:7790 Change-Id: I5c59ea1f097d11f48994f41ac296cfc64121db25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746477 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63169}
-
- 09 Aug, 2019 1 commit
-
-
Mike Stanton authored
The BytecodeGraphBuilder still looks at the heap. This CL completely eliminates heap lookups for: * CreateBlockContext * CreateFunctionContext * CreateEvalContext * CreateCatchContext * CreateWithContext Bug: v8:7790 Change-Id: I8b88215ba14a11955729b33bd0ee57219719666d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745484 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63146}
-