- 15 Jul, 2019 1 commit
-
-
Georg Neis authored
When --concurrent-inlining is on, run bytecode analysis for all relevant functions at serialization time, and store the results in the broker. Change bytecode analysis such that running it for OSR produces information that subsumes the non-OSR case. This lets us avoid doing and storing two analyses for the top-level function in case we do OSR and the function gets inlined into itself. Bug: v8:7790 Change-Id: I7d5df0b2652e6e5c758c85578e51b4f8d041b0d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690959 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62711}
-
- 23 May, 2019 2 commits
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
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}
-
- 29 Apr, 2019 1 commit
-
-
Georg Neis authored
Also const-ify and refactor a few things in BytecodeAnalysis. Change-Id: Ibd261bb67d8c035b1f818e9114d09db08737000d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587384 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61088}
-
- 11 Sep, 2018 1 commit
-
-
Clemens Hammacher authored
The macro has been deprecated since 2016, and it keeps confusing me, so let's just remove it completely from the code base. R=leszeks@chromium.org TBR=mstarzinger@chromium.org, verwaest@chromium.org, jgruber@chromium.org Bug: v8:8015 Change-Id: Ibe1122fd9d2624bc94873d9c51dc8499c54a04fd Reviewed-on: https://chromium-review.googlesource.com/1209322Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#55779}
-
- 23 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
-
- 17 Aug, 2017 1 commit
-
-
Leszek Swirski authored
The accumulator should never be alive when jumping back to a loop header, or jumping out of a loop. This means that as far as far as TurboFan is concerned, we never need to create Phis or LoopExitValues for the accumulator, as its value should not escape the loop. For safety, this also augments the IsLivenessValid DCHECK in the liveness analysis to check that the accumulator is not live in these cases, and amends the bytecode analysis tests to kill the accumulator where necessary to ensure this. As a drive-by, added some comments to the more complex bytecode analysis tests, since figuring out what they were for and how to fix them took a non-trivial amount of time. Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef Reviewed-on: https://chromium-review.googlesource.com/615168 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47388}
-
- 16 Aug, 2017 1 commit
-
-
Leszek Swirski authored
Now that OSR is done during graph building, we no longer have to special-case OSR loops in the loop assignment analysis, as we no longer have the restriction that registers are 'assigned' an OSRValue inside the loop. Bug: v8:6518 Change-Id: Ib4fa139091d77efa16246ddc6e63a10cbb877ee4 Reviewed-on: https://chromium-review.googlesource.com/615167Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47367}
-
- 03 Aug, 2017 1 commit
-
-
Ben L. Titzer authored
R=mstarzinger@chromium.org Bug: Change-Id: I95acea7b33a6e5799399d0891b2a52103f5e4964 Reviewed-on: https://chromium-review.googlesource.com/598072Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47116}
-
- 26 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Reland of https://chromium-review.googlesource.com/c/543042/. Now the OSR phase is only used when OSRing from the ast graph builder. When OSRing from Turbofan, the implementation is now in the graph building phase, at the beginning of the VisitBytecode function. We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, nor nodes for the possible code of the OSRed function which is before the OSRed loops. The trimming and reducing of the OSR phase is not done either. This change in the way the way the OSR is done enabled to remove the workaround to the bug mentioned below. Bug: v8:6112 Bug: v8:6518 Change-Id: Ia02f2138f54fc79cab2f02fed68d9bb522d6ce14 Reviewed-on: https://chromium-review.googlesource.com/584756 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46899}
-
- 21 Jul, 2017 1 commit
-
-
Ross McIlroy authored
This reverts commit 69c8f16d. Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154 BUG=chromium:747154 Original change's description: > [Turbofan] Merged the OSR phase into the graph building phase. > > Now the OSR phase is only used when OSRing from the ast graph builder. > When OSRing from Turbofan, the implementation is now in the graph > building phase, at the beginning of the VisitBytecode function. > We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, > nor nodes for the possible code of the OSRed function which is before > the OSRed loops. > > The trimming and reducing of the OSR phase is not done either. This > change in the way the way the OSR is done enabled to remove the > workaround to the bug mentioned below. > > Bug: v8:6112 > Bug: v8:6518 > Change-Id: I1c9231810b923486d55ea618d550d981d695d797 > Reviewed-on: https://chromium-review.googlesource.com/543042 > Commit-Queue: Alexandre Talon <alexandret@google.com> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46801} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6112, v8:6518 Reviewed-on: https://chromium-review.googlesource.com/581288Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46817}
-
- 20 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Now the OSR phase is only used when OSRing from the ast graph builder. When OSRing from Turbofan, the implementation is now in the graph building phase, at the beginning of the VisitBytecode function. We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, nor nodes for the possible code of the OSRed function which is before the OSRed loops. The trimming and reducing of the OSR phase is not done either. This change in the way the way the OSR is done enabled to remove the workaround to the bug mentioned below. Bug: v8:6112 Bug: v8:6518 Change-Id: I1c9231810b923486d55ea618d550d981d695d797 Reviewed-on: https://chromium-review.googlesource.com/543042 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46801}
-
- 02 Jun, 2017 1 commit
-
-
jarin authored
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
-
- 26 Apr, 2017 1 commit
-
-
Leszek Swirski authored
Instead of calculating the OSR entry point both in the bytecode analysis and in the bytecode graph builder, calculate it once in the analysis and use that calculation in the graph builder. Old TODO from https://codereview.chromium.org/2558093005. Change-Id: I071bc622beb55dc5eddaee25ef28e21fc4b477f0 Reviewed-on: https://chromium-review.googlesource.com/485899 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44888}
-
- 15 Dec, 2016 1 commit
-
-
leszeks authored
Adds assignment tracking to the bytecode analysis pass, and updates bytecode graph builder to only create LoopExitValues for assigned values. Review-Url: https://codereview.chromium.org/2558093005 Cr-Commit-Position: refs/heads/master@{#41719}
-
- 08 Dec, 2016 1 commit
-
-
leszeks authored
Wrap the liveness bitvectors from the bytecode liveness analysis with a helper class, which makes the register/accumulator bits explicit. Review-Url: https://codereview.chromium.org/2552723004 Cr-Commit-Position: refs/heads/master@{#41589}
-
- 05 Dec, 2016 1 commit
-
-
leszeks authored
This allows us to optimise the bytecode liveness analysis to jump directly to previously seen indices. The analysis is optimised to store a stack of loop ends (JumpLoop bytecode indices), and iterate through these indices directly rather than looping through the bytecode array to find them. Review-Url: https://codereview.chromium.org/2536653003 Cr-Commit-Position: refs/heads/master@{#41485}
-
- 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}
-
- 22 Nov, 2016 1 commit
-
-
leszeks authored
Now that we have a JumpLoop bytecode, we can heavily simplify the branch/loop analysis by assuming that only JumpLoop bytecodes are backwards edges, and performing the loop analysis as a single (backwards) pass. This allows us to get rid of the branch analysis entirely, and builds a framework to do liveness analysis in the same pass. Review-Url: https://codereview.chromium.org/2519983002 Cr-Commit-Position: refs/heads/master@{#41194}
-