Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(387)

Unified Diff: src/compiler/osr.h

Issue 816053002: [turbofan] First version of loop peeling. (Closed) Base URL: https://chromium.googlesource.com/v8/v8.git@master
Patch Set: Created 5 years, 11 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « src/compiler/opcodes.h ('k') | src/compiler/pipeline.cc » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: src/compiler/osr.h
diff --git a/src/compiler/osr.h b/src/compiler/osr.h
index fb2267018199213b09ce911eb187b0a061147d9a..89773f0ec55ac5fb6782ba4f7eee182de83bc6ec 100644
--- a/src/compiler/osr.h
+++ b/src/compiler/osr.h
@@ -9,12 +9,10 @@
// TurboFan structures OSR graphs in a way that separates almost all phases of
// compilation from OSR implementation details. This is accomplished with
-// special
-// control nodes that are added at graph building time. In particular, the graph
-// is built in such a way that typing still computes the best types and
-// optimizations and lowering work unchanged. All that remains is to deconstruct
-// the OSR artifacts before scheduling. The helper class below performs the
-// necessary graph rewriting.
+// special control nodes that are added at graph building time. In particular,
+// the graph is built in such a way that typing still computes the best types
+// and optimizations and lowering work unchanged. All that remains is to
+// deconstruct the OSR artifacts before scheduling and code generation.
// Graphs built for OSR from the AstGraphBuilder are structured as follows:
// Start
@@ -36,20 +34,20 @@
// end
// The control structure expresses the relationship that the loop has a separate
-// entrypoint which corresponds to entering the loop directly from start.
+// entrypoint which corresponds to entering the loop directly from the middle
+// of unoptimized code.
// Similarly, the values that come in from unoptimized code are represented with
// {OsrValue} nodes that merge into any phis associated with the OSR loop.
-// The nodes {A} and {B} represent values in the "normal" graph that correspond
-// to the values of those phis before the loop and on any backedges,
-// respectively.
+// In the above diagram, nodes {A} and {B} represent values in the "normal"
+// graph that correspond to the values of those phis before the loop and on any
+// backedges, respectively.
// To deconstruct OSR, we simply replace the uses of the {OsrNormalEntry}
-// control
-// node with {Dead} and {OsrLoopEntry} with start and run the {ControlReducer}.
-// Control reduction propagates the dead control forward, essentially "killing"
-// all the code before the OSR loop. The entrypoint to the loop corresponding
-// to the "normal" entry path will also be removed, as well as the inputs to
-// the loop phis, resulting in the reduced graph:
+// control node with {Dead} and {OsrLoopEntry} with start and run the
+// {ControlReducer}. Control reduction propagates the dead control forward,
+// essentially "killing" all the code before the OSR loop. The entrypoint to the
+// loop corresponding to the "normal" entry path will also be removed, as well
+// as the inputs to the loop phis, resulting in the reduced graph:
// Start
// Dead |^-------------------------+
« no previous file with comments | « src/compiler/opcodes.h ('k') | src/compiler/pipeline.cc » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698