deletions | additions       diff --git a/prev-eval-sol.tex b/prev-eval-sol.tex  index 8f08eab..c5ee67c 100644  --- a/prev-eval-sol.tex  +++ b/prev-eval-sol.tex 
...
The two approaches differ in the points where code specialization is performed. In JIT-based specialization, $f'$ is generated when $f$ is called. In contrast, the OSR-based method interrupts $f$ as it executes, generates a specialized version $f'$, and resumes from it.   Another technical difference, which has substantial performance implications, is the representation level at which optimization occurs in the two approaches. When a function $f$ is first compiled from MATLAB to IIR, and then from IIR to IR, the functions it calls via \feval\ are unknown and the type inference engine is unable to infer the types of their returned 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). The JIT method works on the IIR representation of $f$ and can resort to the full power of type analysis to infer the types of the returned values of $g$, turning the slow generic instructions of $f$ into fast type-specialized instructions in $f'$. On the other hand, OSR-based specialization operates on the IR representation of $f$, which prevents the optimizer from exploiting type inference. As a consequence, for $f'$ to be sound, the direct call to $g$ must be guarded by a condition that checks if$g$ and  the type of its parameters remain the same as observed at the time when $f$ was interrupted. If the guard fails, or the \feval\ target $g$ changes,  the code falls back to executing the original \feval\ instruction. JIT-based specialization is less general than OSR-based specialization, as it only works if the \feval\ argument $g$ is one of the parameters of $f$, but is substantially faster due to the benefits of type inference.