<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 14 (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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
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;}
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;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.EmailStyle19
{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=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>AFAIK, in the ARM case at least, that appears to double the number of cycles the loop takes (5 cycles for the first two instructions due to using the result of a load for address generation vs. 2 cycles for a ldr/cmp going through the fast-path which CMP qualifies for when following a data instruction). In a "real" loop this might not matter as much, but still… <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Gordon<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></a></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] <b>On Behalf Of </b>Matt Johnson<br><b>Sent:</b> Sunday, April 29, 2012 3:35 PM<br><b>To:</b> Fan Dawei<br><b>Cc:</b> llvmdev@cs.uiuc.edu<br><b>Subject:</b> Re: [LLVMdev] Not enough optimisations in the SelectionDAG phase?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On 04/29/2012 01:19 PM, Evan Cheng wrote: <o:p></o:p></p><pre><o:p> </o:p></pre><pre>On Apr 24, 2012, at 11:48 PM, Fan Dawei wrote:<o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>For the following code fragment, <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>; <label>:27 ; preds = %27, %entry<o:p></o:p></pre><pre> %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8<o:p></o:p></pre><pre> %29 = icmp slt i32 %28, 0<o:p></o:p></pre><pre> br i1 %29, label %27, label %loop.exit<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>loop.exit: ; preds = %27<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>llc will generate following MIPS code,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>$BB0_1: <o:p></o:p></pre><pre> lui $3, 32800<o:p></o:p></pre><pre> ori $3, $3, 1032<o:p></o:p></pre><pre> lw $3, 0($3)<o:p></o:p></pre><pre> bltz $3, $BB0_1<o:p></o:p></pre><pre> nop<o:p></o:p></pre><pre># BB#2:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>The two operation lui and ori which are used to calculate memory address actually are loop invariants. They supposed to be moved out of the loop. I thought it might be a limitation of the MIPS backend. Then I tried the ARM backend,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> .LBB1_1: <o:p></o:p></pre><pre> ldr r2, .LCPI1_2<o:p></o:p></pre><pre> ldr r2, [r2]<o:p></o:p></pre><pre> cmp r2, #0<o:p></o:p></pre><pre> blt .LBB1_1<o:p></o:p></pre><pre>@ BB#2: <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The first ldr instruction is to load the address from constant pool. It also should be outside the loop.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I'm not sure if this is because of the optimisations are not enough in the common SelectionDAG optimisation phase, or should this kind of optimisation be implemented by the SelectionDAG instruction lowering phase for each target? <o:p></o:p></pre></blockquote><p class=MsoNormal>I had a mailing list thread on this exact topic last month (see <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048076.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048076.html</a><b> </b>).<br>The underlying cause is that lui and ori are both 'cheap' instructions. It used to be that cheap instructions would not get hoisted at all during Machine LICM.<br>There was a patch a couple weeks back (r154455) that was a bit more aggressive and will hoist cheap instructions if they don't increase register pressure, but it doesn't help us in this case because lui/ori are a pair of dependent ori instructions. There is a chicken-and-egg problem where neither can be hoisted without the other, and MachineLICM is not aggressive enough to recognize chains of dependent, loop-invariant cheap instructions.<br>At the time, the advice was to implement a PseudoInstruction for lui+ori and lower it in a C++ pass, as is done in ARM (see MOVi32imm in ARMInstrInfo.td and ARMExpandPseudoInsts.cpp).<br>I did this for my target and it worked fine, so MIPS could do the same.<br>To me, that solution isn't too satisfying because you have to do this for every multi-instruction TableGen pattern to get them hoisted out of loops, but the philosophy seems to be to keep MachineLICM simple.<br>-Matt<br><br><br><o:p></o:p></p><pre><o:p> </o:p></pre><pre>SelectionDAG doesn't do LICM. Are you running machine-licm pass?<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Evan<o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><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><pre><o:p> </o:p></pre><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><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>