deletions | additions       diff --git a/prev-eval-sol.tex b/prev-eval-sol.tex  index fadb14d..286e616 100644  --- a/prev-eval-sol.tex  +++ b/prev-eval-sol.tex 
...
\paragraph{JIT-based specialization.}   [...] \paragraph{OSR-based specialization.} When This approach triggers an OSR in a function $f$ when  a loop containing an \feval\ becomes hot in a function $f$, an OSR is triggered. hot.  At that time, an optimized version $f'$ of $f$ is generated and control is diverted to $f'$. $f'$ is 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. The optimizer works at IR level and uses the actual values of $g$ and its arguments known (known  at the OSR time time)  to specialize the code. The direct call to $g$ is guarded by a condition that checks if $g$ and the type of its parameters remained remains  the same as observed when the OSR was fired. If the guard fails, the code falls back to executing the original \feval\ instruction. This method overcomes the limitations of JIT-based specialization, supporting optimization of \feval$(g,...)$ calls in functions that do not receive $g$ as a parameter. However, it is substantially slower for two main reasons:  \begin{enumerate}  \item When a function $f$ is first compiled from MATLAB to IR by McVM, the functions it calls via \feval\ are unknown. Hence, unknown and  the type inference engine is unable to infer the  types for of  their returned values, and values. Hence,  these values must be kept boxed in heap-allocated objects and handled with slow generic instructions in the IR representation of $f$ (suitable for handling different types). For this reason, the optimized continuation functions $f'$ generated at OSR points in McVM inherit the slow generic instructions of $f$. \item Guard computation in $f'$ can be rather expensive, as it may require checking many parameters.  \end{enumerate}