deletions | additions       diff --git a/prev-eval-sol.tex b/prev-eval-sol.tex  index a9e25f4..a995d0a 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$g$  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 inference 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 exploting 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, 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.