deletions | additions       diff --git a/case-study.tex b/case-study.tex  index 0104ec6..d5485a6 100644  --- a/case-study.tex  +++ b/case-study.tex 
...
% !TEX root = article.tex  \section{Case Study}  \label{case-study} 
...
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 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$ - and check whether a previously compiled optimized function is available from the code cache. If not, a new function $f_{opt}$ is generated by cloning the IIR representation $f^{IIR}$ of $f$ into $f^{IIR}_{opt}}$ $f^{IIR}_{opt}$  and replacing all the \feval\ calls in the same group of the instrumented one with direct calls to $g$. As a next step, the optimizer asks the IIR compiler to analyze $f^{IIR}_{opt}$ and generate optimized LLVM IR $f^{IR}_{opt}$, also making a copy of the variable map between IIR and IR objects when compiling the direct call corresponding to the \feval\ instruction that triggered the OSR.