Daniele Cono D'Elia edited case-study.tex  over 8 years ago

Commit id: ee27eb33f4d8aa7af1d379cd6e73cf104fdf4073

deletions | additions      

       

We integrated our analysis pass in McVM's analysis manager. In particular, we group \feval\ instructions whose first argument is reached by the same definition, and for each group we mark for instrumentation only instructions not dominated by others, so that the function can be optimized as early as possible at run-time. The analysis pass is also able to determine whether the value of the argument can change across two executions of the same \feval\ instruction, thus discriminating when a run-time guard must be inserted during the run-time optimization phase.  When the IIR compiler processes an annotated \feval\ instruction, it keeps track of the current {\em  variable map (i.e., a map map}  between IIR and IR objects), objects,  the {\tt llvm::BasicBlock*} created for the \feval\ and the {\tt llvm::Value*} object for the used as its  first argument of the \feval. argument.  The last two objects elements  are then  used by the inserter component as basic block and {\tt val} argument for the open-OSR stub, which invokes the optimizer component we are about to present. \newcommand{\gbase}{$g$}  \newcommand{\gOpt}{$g_{opt}$}