<html xmlns:v="urn:schemas-microsoft-com:vml" 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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
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;
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Thanks Philip for looking into LoopVersioning.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> It's not clear to me whether you're proposing a new pass, or extending LICM<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">It’s a new pass, and we are not changing existing LICM functionality.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">LoopVersioning is a memory check based multi versioning optimization. It will creates version
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">of the loop with aggressive alias and the other with conservative (default) alias. Aggressive
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">alias version of loop will have all the memory access marked as no-alias. Because of aggressive
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">aliasing, alias analysis will be sure about memory accesses and it will mark no-alias for all memory
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">accesses in alias sets. This will help some of the optimization to proceed further. One case is LICM
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">PromoteAliasSets (recently refactored as promoteLoopAccessesToScalars).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Post multi versioning in same pass we are planning to call “promoteLoopAccessesToScalars”
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">on aggressive alias versioned loop.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> In particular, I'm concerned about the code size increase that can result from
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> recursive application of loop versioning. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> I think this is an interesting idea, but the profitability heuristics will need to be
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> incredibly carefully tuned.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">We are also concerned about profitability heuristics, and we are trying to minimize the
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">negative impact of this pass. Code size increase is a concern, but we are planning to touch
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">the cases where gain by this optimization will be good enough to justify. For now we made
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">this pass optional.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Profitability analysis contains basic loop structure analysis, loop instructions analysis and
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">loop memory access analysis. We are also trying to ensure the new versioned loop will get
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">benefit by LICM. Apart from this there are few thresholds:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">1) Maximum loop nest threshold allowed is 2(Planning to make this configurable).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">2) Maximum number of pointers threshold in memcheck allowed is 5(Planning to make this configurable).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">I understand profitability plays a vital role here, in current implementation checks added may not
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">be enough for a right profitability analysis. Accepting a possible scope of improvement, as suggested will
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">look into Sanjoy work for IRCE.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> I have not really looked at it, but one high level comment. You've got a couple of really long
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> functions that need to be broken up into semantic pieces. Reviewing in the current form would be hard.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">At this point I’m not expecting a formal review, just emphasizing on the functionality as a part of RFC.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Sure will split out long functions.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">Ashutosh<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> Philip Reames [mailto:listmail@philipreames.com]
<br>
<b>Sent:</b> Wednesday, March 04, 2015 12:16 AM<br>
<b>To:</b> Nema, Ashutosh; llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [LLVMdev] RFC: Loop versioning for LICM<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 02/26/2015 02:31 AM, Nema, Ashutosh wrote:<span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">I like to propose a new loop multi versioning optimization for LICM.
<o:p></o:p></p>
<p class="MsoNormal">For now I kept this for LICM only, but it can be used in multiple places.<o:p></o:p></p>
<p class="MsoNormal">The main motivation is to allow optimizations stuck because of memory
<o:p></o:p></p>
<p class="MsoNormal">alias dependencies. Most of the time when alias analysis is unsure about
<o:p></o:p></p>
<p class="MsoNormal">memory access and it says may-alias. This un surety from alias analysis restrict
<o:p></o:p></p>
<p class="MsoNormal">some of the memory based optimizations to proceed further.<o:p></o:p></p>
<p class="MsoNormal">We observed some cases with LICM, where things are beyond aliasing.
<o:p></o:p></p>
<p class="MsoNormal">In cases where alias analysis is unsure we like to use loop versioning as an alternative.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">I'm concerned about this approach. LICM is deliberately somewhat conservative about aliasing to avoid compile time impact. In practice, we defer some of the harder cases
to GVN in the form of full redundancy and partial redundancy elimination. It's not clear to me that versioning a loop in LICM is a good use of either compile time or code size. In particular, I'm concerned about the code size increase that can result from
recursive application of loop versioning. <br>
<br>
I think this is an interesting idea, but the profitability heuristics will need to be incredibly carefully tuned. It would be really really easy to have a net negative impact on the quality of generated code while doing something that seems like a good idea
within LICM. Can you spell out the profitability heuristics you're planning on using? You might want to look at what Sanjoy has been doing with IRCE. This is a specialized form of Index Set Splitting with the roughly the same problem to solve.
<br>
<br>
Have you looked at trying to make LICM more precise with regards to aliasing? I was looking at this a while back and it seemed like there was plenty of room for cheap changes with payoff here. (One example: a read only call in a loop collapses all alias sets.
Oops.)<br>
<br>
(It's not clear to me whether you're proposing a new pass, or extending LICM. If the former, much of my concern disappears. If the later, you'll need to really justify the complexity.)<br>
<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Loop Versioning will creates version of the loop with aggressive alias and the other
<o:p></o:p></p>
<p class="MsoNormal">with conservative (default) alias. Aggressive alias version of loop will have all the
<o:p></o:p></p>
<p class="MsoNormal">memory access marked as no-alias. These two version of loop will be preceded by a
<o:p></o:p></p>
<p class="MsoNormal">memory runtime check. This runtime check consists of bound checks for all unique memory
<o:p></o:p></p>
<p class="MsoNormal">accessed in loop, and it ensures aliasing of memory. Based on this check result at runtime
<o:p></o:p></p>
<p class="MsoNormal">any of the loops gets executed, if memory is non aliased then aggressive aliasing loop
<o:p></o:p></p>
<p class="MsoNormal">gets executed, else when memory is aliased then non aggressive aliased version gets executed.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">By setting no-alias to memory accessed in aggressive alias version of loop, enable other
<o:p></o:p></p>
<p class="MsoNormal">optimization to continue further.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Following are the top level steps:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">1) Perform loop do versioning feasibility check.<o:p></o:p></p>
<p class="MsoNormal">2) If loop is a candidate for versioning then create a memory bound check, by considering
<o:p></o:p></p>
<p class="MsoNormal"> all the memory access in loop body.<o:p></o:p></p>
<p class="MsoNormal">3) Clone original loop and set all memory access as no-alias in new loop.<o:p></o:p></p>
<p class="MsoNormal">4) Set original loop & versioned loop as a branch target of runtime check result.<o:p></o:p></p>
<p class="MsoNormal">5) Call LICM on aggressive alias versioned of loop(For now LICM is scheduled later and not directly
<o:p></o:p></p>
<p class="MsoNormal"> called from LoopVersioning pass).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Consider following test:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> 1 int foo(int * var1, int * var2, int * var3, unsigned itr) {<o:p></o:p></p>
<p class="MsoNormal"> 2 unsigned i = 0, j = 0;<o:p></o:p></p>
<p class="MsoNormal"> 3 for(; i < itr; i++) {<o:p></o:p></p>
<p class="MsoNormal"> 4 for(; j < itr; j++) {<o:p></o:p></p>
<p class="MsoNormal"> 5 var1[j] = itr + i;<o:p></o:p></p>
<p class="MsoNormal"> 6 var3[i] = var1[j] + var3[i];<o:p></o:p></p>
<p class="MsoNormal"> 7 }<o:p></o:p></p>
<p class="MsoNormal"> 8 }<o:p></o:p></p>
<p class="MsoNormal"> 9 }<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">At line #6 store to var3 can be moved out by LICM(promoteLoopAccessesToScalars)
<o:p></o:p></p>
<p class="MsoNormal">but because of alias analysis un surety about memory access it unable to move it out.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">After Loop versioning IR:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b><Versioned Loop></b><o:p></o:p></p>
<p class="MsoNormal">for.body3.loopVersion: ; preds = %for.body3.loopVersion.preheader, %for.body3.loopVersion<o:p></o:p></p>
<p class="MsoNormal"> %indvars.iv.loopVersion = phi i64 [ %indvars.iv.next.loopVersion, %for.body3.loopVersion ], [ %2, %for.body3.loopVersion.preheader ]<o:p></o:p></p>
<p class="MsoNormal"> %arrayidx.loopVersion = getelementptr inbounds i32* %var1, i64 %indvars.iv.loopVersion<o:p></o:p></p>
<p class="MsoNormal"> store i32 %add, i32* %arrayidx.loopVersion, align 4, !tbaa !1, !alias.scope !11, !noalias !11<o:p></o:p></p>
<p class="MsoNormal"> %indvars.iv.next.loopVersion = add nuw nsw i64 %indvars.iv.loopVersion, 1<o:p></o:p></p>
<p class="MsoNormal"> %lftr.wideiv.loopVersion = trunc i64 %indvars.iv.loopVersion to i32<o:p></o:p></p>
<p class="MsoNormal"> %exitcond.loopVersion = icmp eq i32 %lftr.wideiv.loopVersion, %0<o:p></o:p></p>
<p class="MsoNormal"> br i1 %exitcond.loopVersion, label %for.inc11.loopexit38, label %for.body3.loopVersion<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b><Original Loop></b><o:p></o:p></p>
<p class="MsoNormal">for.body3: ; preds = %for.body3.lr.ph, %for.body3<o:p></o:p></p>
<p class="MsoNormal"> %indvars.iv = phi i64 [ %indvars.iv.next, %for.body3 ], [ %2, %for.body3.lr.ph ]<o:p></o:p></p>
<p class="MsoNormal"> %arrayidx = getelementptr inbounds i32* %var1, i64 %indvars.iv<o:p></o:p></p>
<p class="MsoNormal"> store i32 %add, i32* %arrayidx, align 4, !tbaa !1<o:p></o:p></p>
<p class="MsoNormal"> %8 = load i32* %arrayidx7, align 4, !tbaa !1<o:p></o:p></p>
<p class="MsoNormal"> %add8 = add nsw i32 %8, %add<o:p></o:p></p>
<p class="MsoNormal"> <span style="background:silver;mso-highlight:silver">store i32 %add8, i32* %arrayidx7, align 4, !tbaa !1</span><o:p></o:p></p>
<p class="MsoNormal"> %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1<o:p></o:p></p>
<p class="MsoNormal"> %lftr.wideiv = trunc i64 %indvars.iv to i32<o:p></o:p></p>
<p class="MsoNormal"> %exitcond = icmp eq i32 %lftr.wideiv, %0<o:p></o:p></p>
<p class="MsoNormal"> br i1 %exitcond, label %for.inc11, label %for.body3<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In versioned loop difference is visible, 1 store has moved out.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Following are some high level details about current implementation:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">- LoopVersioning<o:p></o:p></p>
<p class="MsoNormal">LoopVersioning is main class which holds multi versioning functionality.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">- LoopVersioning :: isVersioningBeneficial <o:p></o:p></p>
<p class="MsoNormal">Its member to ‘LoopVersioning’<o:p></o:p></p>
<p class="MsoNormal">Does feasibility check for loop versioning. <o:p></o:p></p>
<p class="MsoNormal">a) Checks layout of loop.<o:p></o:p></p>
<p class="MsoNormal">b) Instruction level check.<o:p></o:p></p>
<p class="MsoNormal">c) memory checks.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in"> <o:p></o:p></p>
<p class="MsoNormal">- LoopVersioning :: versionizeLoop<o:p></o:p></p>
<p class="MsoNormal">a) Clone original loo<o:p></o:p></p>
<p class="MsoNormal">b) Create a runtime memory check.<o:p></o:p></p>
<p class="MsoNormal">c) Add both loops under runtime check results target.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">- RuntimeMemoryCheck<o:p></o:p></p>
<p class="MsoNormal">This class take cares runtime memory check.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">- RuntimeMemoryCheck ::createRuntimeCheck<o:p></o:p></p>
<p class="MsoNormal">It creates runtime memory check.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In this patch used maximum loop nest threshold as 2, and maximum number
<o:p></o:p></p>
<p class="MsoNormal">of pointers in runtime memory check as 5.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Later I like to make this as a utility so others can use it.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Requesting to go through patch for detailed approach.<o:p></o:p></p>
<p class="MsoNormal">Patch available at <a href="http://reviews.llvm.org/D7900">http://reviews.llvm.org/D7900</a><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">If you're expecting review, this needs to go to llvm-commits.
<br>
<br>
I have not really looked at it, but one high level comment. You've got a couple of really long functions that need to be broken up into semantic pieces. Reviewing in the current form would be hard.
<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Suggestions are comments are welcome.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Ashutosh<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>LLVM Developers mailing list<o:p></o:p></pre>
<pre><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><o:p></o:p></pre>
<pre><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
</body>
</html>