- 20 Mar, 2020 1 commit
-
-
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}
-
- 11 Mar, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This CL is a step towards making StackChecks implicit. In a follow-up CL said StackChecks will become implicit within JumpLoops. Cq-Include-Trybots: luci.chromium.try:linux-rel Bug: v8:10149, v8:9960 Change-Id: I5ae247be3f7a58ccdf86398cace30724715767a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062391 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66668}
-
- 09 Mar, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This CL merges nested loops that share the same header offset with its parent loop, by not emitting JumpLoop bytecode for these inner loops. Instead, we generate a Jump to its parent's JumpToHeader (which in turn can be a JumpLoop or another Jump to its parent's JumpToHeader). Originally, every loop had a unique first Bytecode to jump to. Since IterationBody StackChecks are going to become implicit this will no longer be the case. As a note, this CL just sets the foundation that the follow-up CLs will build on top of. Since we have explicit StackChecks, and they are at the beginning of loops we do not have nested loops as of now. Bug: v8:10149, v8:9960 Change-Id: I6daee4d2c6d6216f022228c87c4aa74e163997b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062390 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66626}
-
- 23 May, 2019 1 commit
-
-
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}
-
- 28 Feb, 2019 3 commits
-
-
Leszek Swirski authored
This is a reland of 35269f77 Switches on an expression that unconditionally throws would have all their case statements dead, causing a DCHECK error in the SwitchBuilder. This fixes up the DCHECK to allow dead labels. Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org Bug: chromium:934166 Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4 Reviewed-on: https://chromium-review.googlesource.com/c/1494535Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59948}
-
Sigurd Schneider authored
This reverts commit 35269f77. Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792 Original change's description: > [ignition] Skip binding dead labels > > BytecodeLabels for forward jumps may create a dead basic block if their > corresponding jump was elided (due to it dead code elimination). We can > avoid generating such dead basic blocks by skipping the label bind when > no corresponding jump has been observed. This works because all jumps > except JumpLoop are forward jumps, so we only have to special case one > Bind for loop headers to bind unconditionally. > > Since Binds are now conditional on a jump existing, we can no longer rely > on using Bind to get the current offset (e.g. at the beginning of a try > block). Instead, we now expose the current offset in the bytecode array > writer. Conveniently, this means that we can be a bit smarter about basic > blocks around these statements. > > As a drive-by, remove the unused Bind(target,label) function. > > Bug: chromium:934166 > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 > Reviewed-on: https://chromium-review.googlesource.com/c/1488763 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59942} TBR=rmcilroy@chromium.org,leszeks@chromium.org Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:934166 Reviewed-on: https://chromium-review.googlesource.com/c/1494534Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59947}
-
Leszek Swirski authored
BytecodeLabels for forward jumps may create a dead basic block if their corresponding jump was elided (due to it dead code elimination). We can avoid generating such dead basic blocks by skipping the label bind when no corresponding jump has been observed. This works because all jumps except JumpLoop are forward jumps, so we only have to special case one Bind for loop headers to bind unconditionally. Since Binds are now conditional on a jump existing, we can no longer rely on using Bind to get the current offset (e.g. at the beginning of a try block). Instead, we now expose the current offset in the bytecode array writer. Conveniently, this means that we can be a bit smarter about basic blocks around these statements. As a drive-by, remove the unused Bind(target,label) function. Bug: chromium:934166 Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3 Reviewed-on: https://chromium-review.googlesource.com/c/1488763 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59942}
-
- 21 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This changes a few bits about how continuation counters are handled. It introduces a new mechanism that allows removal of a continuation range after it has been created. If coverage is enabled, we run a first post-processing pass on the AST immediately after parsing, which removes problematic continuation ranges in two situations: 1. nested continuation counters - only the outermost stays alive. 2. trailing continuation counters within a block-like structure are removed if the containing structure itself has a continuation. R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org Bug: v8:8381, v8:8539 Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3 Reviewed-on: https://chromium-review.googlesource.com/c/1339119Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58443}
-
- 24 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Instead of building suspend_ids in the AST numbering, collect suspend counts in the parser and assigning suspend ids during bytecode generation. Bug: v8:7178 Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0 Reviewed-on: https://chromium-review.googlesource.com/817598 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50830}
-
- 09 Nov, 2017 1 commit
-
-
jgruber authored
Move block coverage logic for TryCatchStatement and TryFinallyStatement nodes into builder classes. Bug: v8:6000 Change-Id: I0402ef78a54d6ba1bae62214f16aabfebbd7c581 Reviewed-on: https://chromium-review.googlesource.com/758645 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49268}
-
- 21 Jul, 2017 2 commits
-
-
jgruber authored
This refactors logic for handling IfStatement and Conditional nodes (including block-coverage related slot and counter creation) into a new control-flow builder. Bug: v8:6000 Change-Id: Ib5b1724bdf8571fb55d310be79cc60dcf5473b81 Reviewed-on: https://chromium-review.googlesource.com/579509Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46818}
-
jgruber authored
Move block coverage slot creation into BreakableControlFlowBuilder for Switch/Loop/Block constructs. Bug: v8:6000 Change-Id: I4fa7fdb2ffbb56fd1016c22741458c103b42219c Reviewed-on: https://chromium-review.googlesource.com/571808 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46808}
-
- 13 Jul, 2017 1 commit
-
-
jgruber authored
Both labeled blocks: l0: { break l0; } and blocks containing jump statements (break, return, continue) require a continuation counter to correctly display coverage. Bug: v8:6000 Change-Id: I3ae8ddd3d9f6c087622482b86014dd583b774b71 Reviewed-on: https://chromium-review.googlesource.com/568024Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46644}
-
- 19 Jun, 2017 1 commit
-
-
jgruber authored
Track execution counts of the continuations of block structures (e.g. IfStatements) to capture cases in which execution does not continue after a block. For example: for (;;) { return; } // Never reached, tracked by continuation counter. A continuation counter only has a start position; it's range is implicitly until the next sibling range or the end of the parent range. Bug: v8:6000 Change-Id: I8e8f1f5b140b64c86754b916e626eb50f0707d70 Reviewed-on: https://chromium-review.googlesource.com/530846 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#46006}
-
- 15 May, 2017 1 commit
-
-
Leszek Swirski authored
Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
-
- 05 Apr, 2017 1 commit
-
-
Ross McIlroy authored
Move the ToBoolean elision in the BytecodeGenerator instead of the peephole optimizer. Adds a TypeHint mechanism to the ExpressionResult to enable passing of type hints through the ast visitor. BUG=v8:6194 Change-Id: Ic55506ba11b213f7459250004d3f18cab04ee9b3 Reviewed-on: https://chromium-review.googlesource.com/467208 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44415}
-
- 09 Jan, 2017 1 commit
-
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
- 29 Nov, 2016 3 commits
-
-
leszeks authored
Replaces the graph-based liveness analyzer in the bytecode graph builder with an initial bytecode-based liveness analysis pass, which is added to the existing loop extent analysis. Now the StateValues in the graph have their inputs initialised to optimized_out, rather than being modified after the graph is built. Review-Url: https://codereview.chromium.org/2523893003 Cr-Commit-Position: refs/heads/master@{#41355}
-
leszeks authored
Revert of [ignition/turbo] Perform liveness analysis on the bytecodes (patchset #17 id:320001 of https://codereview.chromium.org/2523893003/ ) Reason for revert: Breaks the build: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14886 Original issue's description: > [ignition/turbo] Perform liveness analysis on the bytecodes > > Replaces the graph-based liveness analyzer in the bytecode graph builder > with an initial bytecode-based liveness analysis pass, which is added to > the existing loop extent analysis. > > Now the StateValues in the graph have their inputs initialised to > optimized_out, rather than being modified after the graph is built. > > Committed: https://crrev.com/1852300954c216c29cf93444430681d213e87925 > Cr-Commit-Position: refs/heads/master@{#41344} TBR=jarin@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2541443002 Cr-Commit-Position: refs/heads/master@{#41346}
-
leszeks authored
Replaces the graph-based liveness analyzer in the bytecode graph builder with an initial bytecode-based liveness analysis pass, which is added to the existing loop extent analysis. Now the StateValues in the graph have their inputs initialised to optimized_out, rather than being modified after the graph is built. Review-Url: https://codereview.chromium.org/2523893003 Cr-Commit-Position: refs/heads/master@{#41344}
-
- 13 Sep, 2016 1 commit
-
-
mstarzinger authored
This introduces a new {JumpLoop} bytecode to combine the OSR polling mechanism modeled by {OsrPoll} with the actual {Jump} performing the backwards branch. This reduces the overall size and also avoids one additional dispatch. It also makes sure that OSR polling is only done within real loops. R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2331033002 Cr-Commit-Position: refs/heads/master@{#39384}
-
- 19 Aug, 2016 1 commit
-
-
klaasb authored
Changes the control flow builder classes to make use of the BytecodeLabels helper class. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2254493002 Cr-Commit-Position: refs/heads/master@{#38744}
-
- 02 Aug, 2016 1 commit
-
-
mstarzinger authored
This makes sure we are not inserting {OsrPoll} instructions for any statements that are not actually loops and have no back edges. Without back edges the {BytecodeGraphBuilder} is unable to deduce loop ranges and hence cannot construct a graph for OSR entry. R=neis@chromium.org TEST=mjsunit/regress/regress-5252 BUG=v8:5252 Review-Url: https://codereview.chromium.org/2200733002 Cr-Commit-Position: refs/heads/master@{#38233}
-
- 22 Jul, 2016 1 commit
-
-
yangguo authored
This is in preparation to implementing exception prediction for async functions. Each handler table entry can now predict "caught", "uncaught", or "promise". The latter indicates that the exception will lead to a promise rejection. To mark the relevant try-catch blocks, we add a new native syntax. try { } %catch (e) { } indicates a TryCatchStatement with the "promise" prediction. The previous implementation of using the function to tell the relevant try-catch apart from inner try-catch blocks will not work for async functions since these can have inner try-catch blocks inside the same function. BUG=v8:5167 Review-Url: https://codereview.chromium.org/2161263003 Cr-Commit-Position: refs/heads/master@{#37966}
-
- 12 Jul, 2016 1 commit
-
-
neis authored
This solves an issue with throws inside for-of always being marked as caught. BUG=v8:5183 Review-Url: https://codereview.chromium.org/2146493002 Cr-Commit-Position: refs/heads/master@{#37686}
-
- 04 May, 2016 1 commit
-
-
neis authored
We sometimes used to continue by jumping _back_ to the condition check at the top of the loop. After my recent generator-related changes, that check is no longer at the loop header, so a continue could create an additional loop. In order to avoid this, we now always set the continue target to be the first instruction following the loop body. BUG= Review-Url: https://codereview.chromium.org/1943383003 Cr-Commit-Position: refs/heads/master@{#36029}
-
- 27 Apr, 2016 1 commit
-
-
neis authored
This is necessary to eventually build a turbofan graph. BUG=v8:4907 LOG=n Review URL: https://codereview.chromium.org/1901713003 Cr-Commit-Position: refs/heads/master@{#35820}
-
- 12 Feb, 2016 2 commits
-
-
mstarzinger authored
Reland of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1695613002/ ) Reason for revert: No fix needed, original CL was perfectly fine! Original issue's description: > Revert of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1690973002/ ) > > Reason for revert: > Depends on the reverted https://codereview.chromium.org/1691723002 > > Original issue's description: > > [interpreter] Correctly thread through catch prediction. > > > > This change correctly sets the {CatchPrediction} field in exception > > handler tables for bytecode and optimized code. It also adds tests > > independent of promise handling for this prediction, to ensure all our > > backends are in sync on their prediction. > > > > R=rmcilroy@chromium.org,yangguo@chromium.org > > TEST=mjsunit/compiler/debug-catch-prediction > > BUG=v8:4674 > > LOG=n > > > > Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b > > Cr-Commit-Position: refs/heads/master@{#33906} > > TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:4674 > > Committed: https://crrev.com/c5229b311968fd638a6cd537c341b1055eb7be97 > Cr-Commit-Position: refs/heads/master@{#33922} TBR=rmcilroy@chromium.org,yangguo@chromium.org,adamk@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4674 Review URL: https://codereview.chromium.org/1689113004 Cr-Commit-Position: refs/heads/master@{#33933}
-
adamk authored
Revert of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1690973002/ ) Reason for revert: Depends on the reverted https://codereview.chromium.org/1691723002 Original issue's description: > [interpreter] Correctly thread through catch prediction. > > This change correctly sets the {CatchPrediction} field in exception > handler tables for bytecode and optimized code. It also adds tests > independent of promise handling for this prediction, to ensure all our > backends are in sync on their prediction. > > R=rmcilroy@chromium.org,yangguo@chromium.org > TEST=mjsunit/compiler/debug-catch-prediction > BUG=v8:4674 > LOG=n > > Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b > Cr-Commit-Position: refs/heads/master@{#33906} TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4674 Review URL: https://codereview.chromium.org/1695613002 Cr-Commit-Position: refs/heads/master@{#33922}
-
- 11 Feb, 2016 1 commit
-
-
mstarzinger authored
This change correctly sets the {CatchPrediction} field in exception handler tables for bytecode and optimized code. It also adds tests independent of promise handling for this prediction, to ensure all our backends are in sync on their prediction. R=rmcilroy@chromium.org,yangguo@chromium.org TEST=mjsunit/compiler/debug-catch-prediction BUG=v8:4674 LOG=n Review URL: https://codereview.chromium.org/1690973002 Cr-Commit-Position: refs/heads/master@{#33906}
-
- 22 Jan, 2016 1 commit
-
-
mstarzinger authored
This models function local control flow through try-finally constructs using a token dispatch mechanism. All paths through the finally block are assigned a token, at the end of the finally block a switch construct dispatches according to this token. R=oth@chromium.org,rmcilroy@chromium.org BUG=v8:4674 LOG=n Review URL: https://codereview.chromium.org/1613443002 Cr-Commit-Position: refs/heads/master@{#33465}
-
- 20 Jan, 2016 1 commit
-
-
mstarzinger authored
This implements a first version of exception handler table construction within the interpreter. Note that the local control flow for try-catch and try-finally statements is still off, and also stack unwinding does not yet respect interpreter frames. But generated handler tables should be populated correctly already. R=oth@chromium.org BUG=v8:4674 LOG=n Review URL: https://codereview.chromium.org/1607433005 Cr-Commit-Position: refs/heads/master@{#33400}
-
- 21 Dec, 2015 1 commit
-
-
oth authored
A pre-requisite for this change was changing the interpreter to use Runtime::ForInStep to bring the interpreter implementation closer to the turbofan implementation. Also required to flatten out the cache parameters into the interpreter frame for de-opt. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1531693002 Cr-Commit-Position: refs/heads/master@{#32986}
-
- 16 Dec, 2015 2 commits
-
-
oth authored
BUG=V8:4280 LOG=N Review URL: https://codereview.chromium.org/1524893003 Cr-Commit-Position: refs/heads/master@{#32912}
-
oth authored
This change adds support for local control flow when building graphs from bytecode. The change ensures loop emitted from the bytecode generator are in natural order so the only back branches are for loops. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1502243002 Cr-Commit-Position: refs/heads/master@{#32911}
-
- 30 Oct, 2015 1 commit
-
-
rmcilroy authored
Adds support for switch statments to the interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1415093006 Cr-Commit-Position: refs/heads/master@{#31687}
-
- 29 Oct, 2015 1 commit
-
-
oth authored
For..in introduces 3 new bytecodes ForInPrepare, ForInNext, and ForInDone to start a for..in loop, get the next element, and check if the loop is done. For..in builds upon new LoopBuilder constructs for conditionally breaking and continuing during iteration: BreakIf{Null|Undefined} and ContinueIf{Null|Undefined}. New conditional jump bytecodes support this succinctly: JumpIfNull and JumpIfUndefined. Add missing check to BytecodeLabel that could allow multiple forward referencess to the same label which is not supported. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1422033002 Cr-Commit-Position: refs/heads/master@{#31651}
-
- 01 Oct, 2015 1 commit
-
-
oth authored
Improve bytecode generation for if when there's no else clause. Display target addresses for jump instructions in Bytecode::Disassemble(). BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1373903005 Cr-Commit-Position: refs/heads/master@{#31052}
-