Author: Carl Friedrich Bolz <cfb...@gmx.de>
Branch: extradoc
Changeset: r3765:d40d14eafd53
Date: 2011-06-21 14:05 +0200
http://bitbucket.org/pypy/extradoc/changeset/d40d14eafd53/
Log: fix two XXXs, start adding some minimal notes to the related work
section
diff --git a/talk/iwtc11/paper.tex b/talk/iwtc11/paper.tex
--- a/talk/iwtc11/paper.tex
+++ b/talk/iwtc11/paper.tex
@@ -177,9 +177,7 @@
of them are well-known loop optimizations. However, the way to implement them
is
a lot simpler than directly implementing loop-aware optimizations.
-XXX "bridge" is not a standard term
-
-XXX loop peeling does a lot more than loop-invariant code motion
+% loop peeling does a lot more than loop-invariant code motion
% take this loop as an example:
% [i1, i2]
% i3 = i1 + 1
@@ -475,7 +473,12 @@
the preamble will be executed only once while the peeled loop will
be used for every further iteration. New variable names have to be
introduced in the entire copied trace in order to maintian the SSA-property.
-When applying the following optimizations to this two-iteration trace
+Note that the peeled loop is not necessary the \emph{first} iteration of the
+loop execution, it is general enough to correspond to any iteration of the
loop.
+However, the peeled loop can then be optimized using the assumption that a
+previous iteration has happened.
+
+When applying optimizations to this two-iteration trace
some care has to taken as to how the arguments of the two
\lstinline{jump} operations and the input arguments of the peeled loop are
treated. It has to be ensured that the peeled loop stays a proper
@@ -593,9 +596,6 @@
\subsection{Redundant Guard Removal}
-XXX should we have a mention where in the previous papers those optimizations
-are discussed?
-
No special concerns needs to be taken when implementing redundant
guard removal together with loop peeling. The guards from
the preamble might make the guards of the peeled loop
@@ -814,7 +814,7 @@
\section{Benchmarks}
The loop peeling optimization was implemented in the PyPy
-framework. That means that the JIT-compilers generated for all
+framework in about 450 lines of RPython code. That means that the
JIT-compilers generated for all
interpreters implemented within PyPy now can take advantage of
it. Benchmarks have been executed for a few different interpreters and
we see improvements in several cases. The ideal loop for this optimization
@@ -967,6 +967,15 @@
\section{Related Work}
\label{sec:related}
+All the optimizations presented here are completely standard \cite{XXX} [dragon
+book or similar].
+
+LuaJIT does the same
+
+SPUR does all these optimizations manually, moves allocations out of loop but
+does not explode objects
+
+
XXX
% section Related Work (end)
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
http://mail.python.org/mailman/listinfo/pypy-commit
