<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:596447621;
mso-list-type:hybrid;
mso-list-template-ids:-1649500186 -435359912 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:58.5pt;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:94.5pt;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:130.5pt;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:166.5pt;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:202.5pt;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:238.5pt;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:274.5pt;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:310.5pt;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:346.5pt;
text-indent:-9.0pt;}
@list l1
{mso-list-id:972100097;
mso-list-type:hybrid;
mso-list-template-ids:5952756 -1452374322 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Johannes,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I definitely agree that LLVM needs better support for optimizing parallel programs. Comments inline:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Johannes Doerfert <jdoerfert@anl.gov><br>
<b>Date: </b>Wednesday, June 6, 2018 at 10:52 AM<br>
<b>To: </b>LLVM-Dev <llvm-dev@lists.llvm.org><br>
<b>Cc: </b>Hal Finkel <hfinkel@anl.gov>, TB Schardl <neboat@mit.edu>, "Adve, Vikram Sadanand" <vadve@illinois.edu>, "Tian, Xinmin" <xinmin.tian@intel.com>, "llvmpar@lists.cs.illinois.edu" <llvmpar@lists.cs.illinois.edu><br>
<b>Subject: </b>[RFC] Abstract Parallel IR Optimizations<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">This is an RFC to add analyses and transformation passes into LLVM to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">optimize programs based on an abstract notion of a parallel region.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> == this is _not_ a proposal to add a new encoding of parallelism ==<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Actually, I suspect that your three “abstract” interfaces below (ParallelRegionInfo, ParallelCommunicationInfo, ParallelIR/Builder) *<b>are</b>* a parallel IR definition, and what you call the “implementations” essentially encapsulate *<b>target-specific</b>*
variations. IOW, this looks like a perhaps-very-preliminary parallel IR, not some generic abstract interface. I can only suspect this because I don’t have any information about what info or operations these interfaces provide.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In fact, I think it *<b>is</b>* a good idea to have a proper parallel IR to support the kinds of optimizations you’re describing. I just don’t think you can define a universal parallel IR for all the parallel languages and targets that
LLVM may want to support. At a minimum, I think we need to experiment more before committing to one (*if* one proved enough).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Instead of defining a specific parallel IR or interface, as you’re trying to do, it would be much better to provide IR-independent hooks in LLVM so that different parallel IRs can sit “above” the LLVM representation and support these and
other optimizations. Your IR (or IR implementations, whatever you call them) could be layered in this way.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The earlier RFC that Hal Finkel and Xinmin Tian circulated were for such a set of hooks. In fact, these hooks also work on regions, but are much more limited and are *<b>not</b>* meant to support parallel passes themselves: those are left
to any IR built above them.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As you know, we (Hal, Xinmin, TB Schardl, George Stelle, Hashim Sharif, I, and a few others) are trying to refine that proposal to provide examples of multiple IRs the hooks can support, and to make a clearer argument for the soundness
and correctness impact of the hooks on LLVM passes. You’ve been invited to our conference calls and to edit the Google Doc. It would be valuable if you could add examples of how your IR information could be connected to LLVM via these hooks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">More specific questions below.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">We currently perform poorly when it comes to optimizations for parallel<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">codes. In fact, parallelizing your loops might actually prevent various<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">optimizations that would have been applied otherwise. One solution to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">this problem is to teach the compiler about the semantics of the used<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">parallel representation. While this sounds tedious at first, it turns<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">out that we can perform key optimizations with reasonable implementation<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">effort (and thereby also reasonable maintenance costs). However, we have<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">various parallel representations that are already in use (KMPC,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">GOMP, CILK runtime, ...) or proposed (Tapir, IntelPIR, ...).
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Our proposal seeks to introduce parallelism specific optimizations for<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">multiple representations while minimizing the implementation overhead.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">This is done through an abstract notion of a parallel region which hides<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">the actual representation from the analysis and optimization passes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In general, for analysis and optimization passes to work with multiple representations, you’d need to have a pretty rich abstract notion of a parallel region. I suspect that your design is pretty OpenMP-specific. Even within that context,
it would have to capture quite a rich set of parallel constructs. Can you describe what exactly is your abstract notion of a parallel region, and how is it different from a concrete representation?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">In<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">the schemata below, our current five optimizations (described in detail<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">here [0]) are shown on the left, the abstract parallel IR interface is<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">is in the middle, and the representation specific implementations is on<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">the right.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Optimization (A)nalysis/(T)ransformation Impl.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> ---------------------------------------------------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> CodePlacementOpt \ /---> ParallelRegionInfo (A) ---------|-> KMPCImpl (A)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> RegionExpander -\ | | GOMPImpl (A)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> AttributeAnnotator -|-|---> ParallelCommunicationInfo (A) --/ ...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> BarrierElimination -/ |<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">VariablePrivatization / \---> ParallelIR/Builder (T) -----------> KMPCImpl (T)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I wasn’t able to understand parts of this figure. What info do ParallelRegionInfo() and ParallelCommunicationInfo() provide? What operations does ParallelIR/Builder provide?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">In our setting, a parallel region can be an outlined function called<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">through a runtime library but also a fork-join/attach-reattach region<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">embedded in an otherwise sequential code. The new optimizations will<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">provide parallelism specific optimizations to all of them (if<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">applicable). There are various reasons why we believe this is a<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">worthwhile effort that belongs into the LLVM codebase, including:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Before adding something this broad into the LLVM code base, I think we need to understand a whole slew of things about it, starting with the questions above.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:22.5pt;mso-list:l0 level1 lfo2">We improve the performance of parallel programs, today.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There are a number of important parallel languages and both language-specific and target-specific parallel optimizations. Just because these five optimizations improve OpenMP program performance isn’t enough to justify adding a new parallel
IR (or interface) to LLVM, without knowing whether other languages, targets and optimizations could be correctly and effectively implemented using this approach.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> 2) It serves as a meaningful baseline for future discussions on<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> (optimized) parallel representations.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We can’t just add a new parallel IR design (abstract or concrete) to mainline just to serve as a baseline for future discussions.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> 3) It allows to determine the pros and cons of the different schemes<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> when it comes to actual optimizations and inputs.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Same problem.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> 4) It helps to identify problems that might arise once we start to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> transform parallel programs but _before_ we commit to a specific<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> representation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I suspect you *<b>are</b>* committing to a specific representation, although we can’t be sure until you provide more details.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Our prototypes for the OpenMP KMPC library (used by clang) already shows<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">significant speedups for various benchmarks [0]. It also exposed a (to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">me) prior unknown problem between restrict/noalias pointers and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">(potential) barriers (see Section 3 in [0]).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">We are currently in the process of cleaning the code, extending the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">support for OpenMP constructs and adding a second implementation for a<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">embedded parallel regions. Though, a first horizontal prototype<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">implementation is already available for review [1].<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Inputs of any kind are welcome and reviewers are needed!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> Johannes<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">[0] <a href="http://compilers.cs.uni-saarland.de/people/doerfert/par_opt18.pdf">
http://compilers.cs.uni-saarland.de/people/doerfert/par_opt18.pdf</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">[1] <a href="https://reviews.llvm.org/D47300">
https://reviews.llvm.org/D47300</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-- <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Johannes Doerfert<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">PhD Student / Researcher<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Compiler Design Lab (Professor Hack) / Argonne National Laboratory<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Saarland Informatics Campus, Germany / Lemont, IL 60439, USA<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Building E1.3, Room 4.31<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Tel. +49 (0)681 302-57521 : <a href="mailto:doerfert@cs.uni-saarland.de">
doerfert@cs.uni-saarland.de</a> / <a href="mailto:jdoerfert@anl.gov">jdoerfert@anl.gov</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Fax. +49 (0)681 302-3065 : <a href="http://www.cdl.uni-saarland.de/people/doerfert">
http://www.cdl.uni-saarland.de/people/doerfert</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo1"><o:p> </o:p></li></ul>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal">—Vikram Adve<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">// Interim Head, Department of Computer Science<o:p></o:p></p>
<p class="MsoNormal">// Donald B. Gillies Professor of Computer Science<br>
// University of Illinois at Urbana-Champaign<br>
// Admin Assistant: Amanda Foley - <a href="mailto:ajfoley2@illinois.edu">ajfoley2@illinois.edu</a><br>
// Google Hangouts: <a href="mailto:vikram.s.adve@gmail.com">vikram.s.adve@gmail.com</a> || Skype: vikramsadve<br>
// Research page: <a href="http://vikram.cs.illinois.edu/">http://vikram.cs.illinois.edu</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
</body>
</html>