deletions | additions       diff --git a/figures/isordascto/caption.tex b/figures/isordascto/caption.tex  index 59e02a6..5f5f2d0 100644  --- a/figures/isordascto/caption.tex  +++ b/figures/isordascto/caption.tex 
...
\label{fig:isordascto} LLVM IR version of faster faster, specialized  variant of  {\tt isordasc} isord}  (\myfigure\ref{fi:isord-example}) instrumented for OSR. Instrumentation additions are in grey. The original function entry block is unreachable after instrumentation and is eliminated (struck-through code fragments). diff --git a/figures/isordfrom/caption.tex b/figures/isordfrom/caption.tex  index 52e4cc5..f3859fe 100644  --- a/figures/isordfrom/caption.tex  +++ b/figures/isordfrom/caption.tex 
...
\label{fig:isordfrom} LLVM IR version of base function {\tt isord} of \myfigure\ref{fi:isord-example} (\myfigure\ref{fi:isord-example})  instrumented for resolved OSR. The OSR is fired at the beginning of the loop body after 1000 iterations. Additions resulting from the instrumentation are in grey. diff --git a/overview.tex b/overview.tex  index c67d3c5..490ec69 100644  --- a/overview.tex  +++ b/overview.tex 
...
Our implementation targets two general scenarios: 1) {\em resolved OSR}: \fvariant\ is known before executing \fbase\ as in the deoptimization example discussed above; 2) {\em open OSR}: \fvariant\ is generated when the OSR is fired, supporting deferred and profile-guided compilation strategies. In both cases, \fbase\ is instrumented before its execution to incorporate the OSR machinery. We call such OSR-instrumented version \fosrfrom.  In the resolved OSR scenario (see \myfigure\ref{fi:overview-osr-final}), instrumentation consists of adding a check of the OSR condition and, if it is satisfied, a tail call that fires the OSR. The called function is an instrumented version of \fvariant, which we call \fosrto. The assumption is that \fosrto\ produces the same side-effects and return value that one would obtain by \fbase\ if no OSR was performed. Differently from \fvariant, \fosrto\ takes as input all live variables of \fbase\ at \osrpoint, executes an optional compensation code to fix the computation state ({\tt comp\_code}), and then jumps to a point \textsf{L'} from which execution can continue. The OSR practice often makes the conservative assumption that execution can always continue with the very same program state as the base function. However, this assumption may reduce the number of points where sound OSR transitions can be fired. Supporting compensation code in our framework adds flexibility, allowing OSR transitions to happen at arbitrary places in the base function.  \ifdefined\noauthorea  \begin{figure}[t]  \begin{center} 
...
\end{figure}  \fi  In the resolved OSR scenario (see \myfigure\ref{fi:overview-osr-final}), instrumentation consists of adding a check of the OSR condition and, if it is satisfied, a tail call that fires the OSR. The called function is an instrumented version of \fvariant, which we call \fosrto. The assumption is that \fosrto\ produces the same side-effects and return value that one would obtain by \fbase\ if no OSR was performed. Differently from \fvariant, \fosrto\ takes as input all live variables of \fbase\ at \osrpoint, executes an optional compensation code to fix the computation state ({\tt comp\_code}), and then jumps to a point \textsf{L'} from which execution can continue. The OSR practice often makes the conservative assumption that execution can always continue with the very same program state as the base function. However, this assumption may reduce the number of points where sound OSR transitions can be fired. Supporting compensation code in our framework adds flexibility, allowing OSR transitions to happen at arbitrary places in the base function.  \ifdefined\noauthorea  \begin{figure}[h!] \begin{figure}[t]  \begin{center}  \includegraphics[width=1.0\columnwidth]{figures/overview-osr-open/overview-osr-open.eps}  \caption{\protect\input{figures/overview-osr-open/caption}}