deletions | additions       diff --git a/article.tex b/article.tex  index 7885164..b4ce870 100644  --- a/article.tex  +++ b/article.tex 
...
\input{overview}  \input{osr-llvm}  \input{case-study}  \input{prev-eval-sol}  \input{experim}  \input{related}  \input{conclusions}  diff --git a/prev-eval-sol.tex b/prev-eval-sol.tex  index 3bb94e0..27934a2 100644  --- a/prev-eval-sol.tex  +++ b/prev-eval-sol.tex 
...
%%%%%%%%%%%%%%%%%%%%%%% % !TEX root = article.tex  \subsection{Comparison to previous approaches}  \label{ss:prev-eval-sol} 
...
[...]  \paragraph{OSR-based specialization.} When a loop containing an \feval\ becomes hot in a function $f$, an OSR is triggered. At that time, a specialized an optimized  version $f'$ of $f$ is generated and control is diverted to $f'$. $f'$ is generated created  by an optimizer that attempts to replace an \feval$(g,x,y,z...)$ instruction with a direct call $g(x,y,z,...)$ with unboxed parameters, leveraging the fact that parameters. The optimizer uses  the actual values of $g$ and its argumentsare  known at the  OSR time. time to specialize the code.  The direct call is guarded by a condition that checks if $g$ and the type of its parameters remain the same as observed when the OSR was fired. If the guard fails, the code falls back to executing the original \feval\ instruction. While this method overcomes the limitations of JIT-based specialization, supporting optimization of \feval\ instructions without , it is substantially slower for two main reasons:  \begin{enumerate}