deletions | additions       diff --git a/case-study.tex b/case-study.tex  index 11574c5..916d699 100644  --- a/case-study.tex  +++ b/case-study.tex 
...
\item An analysis pass for {\tt feval} instructions in the IIR representation of a function  \item An extension for the IIR compiler to track the correspondence between IIR and IR objects at {\tt feval} calls  \item A helper component to insert OSR points in the IR at IIR locations annotated during the analysis pass  \item A callback component invoked optimizer triggered  at OSR points, which in turn is made of: \begin{enumerate}  \item A profile-driven IIR generator to replace {\tt feval} calls with direct calls  \item A helper component to lower the optimized IIR function to IR and construct a state mapping  
...
The analysis pass is also able to determine whether the value of the argument can change across two executions of the same {\tt feval} instruction, thus discriminating when a run-time guard must be inserted during the run-time optimization phase. Compared to the OSR-based approach by Lameed and Hendren, our solution is cheaper because the types for the other arguments do not need to be cached or guarded: as we will see later, the type inference engine will compute the most accurate yet sound type information in the analysis of the optimized IIR where direct calls are used.  When the IIR compiler processes an annotated {\tt feval} instruction, it will store in the metadata of the function version being compiled a copy of its variable map (i.e., a map between IIR and IR objects), the current {\tt llvm::BasicBlock*} created for the call and the {\tt llvm::Value*} object corresponding to the first argument for the {\tt feval}. The last two objects are used by the helper component as source label and profiling value for inserting an open OSR point, with the copy of the variable map being passed (along with other information) as {\tt extra} field. The open OSR open-OSR  stub will in turn invoke the callback optimizer  component we are about to describe in the next subsection. \subsection{Generating optimized code}  The core of the optimization pipeline is the callback optimizer component, that is responsible for generating optimized code for the current function $f$ using profiling (i.e., the object containing the first argument for \feval\) and contextual information passed from the open-OSR stub. As a first step, the optimizer will process the profiling object to resolve the target of the call, which we call $g$. Then, a new function $f_OSR$ is generated by cloning the IIR representation $R$ of $f$ and replacing all the \feval\ instructions in the same group of the instrumented one with direct calls to $g$.