<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 12 (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";}
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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@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 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'>Hi Lang,<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'> Just one more quick question… in LiveIntervalAnalysis.cpp In <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'>SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx)<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'>Did you really mean to use<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'> for (MachineRegisterInfo::use_nodbg_iterator<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> UI = MRI.use_nodbg_begin(Reg),<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> UE = MRI.use_nodbg_end();<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> UI != UE; UI.skipInstruction()) {}<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'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aren’t we currently dealing with units, not registers ?<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'>SlotIndex LastUse = findLastUseBefore(LI->reg, OldIdx);<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'> …and isn’t MRI.use_nodbg_begin(Reg) expects a register, not a unit? …or did I got it wrong again… Sorry to bug you on this.<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'>Sergei<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:10.5pt;font-family:Consolas;color:#1F497D'>---<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation</span><span style='font-size:10.5pt;font-family:Consolas;color:#1F497D'><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><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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Lang Hames [mailto:lhames@gmail.com] <br><b>Sent:</b> Thursday, August 30, 2012 3:17 PM<br><b>To:</b> Sergei Larin<br><b>Cc:</b> Andrew Trick; LLVM Developers Mailing List<br><b>Subject:</b> Re: [LLVMdev] Assert in LiveInterval update<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Sergei, Andy,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Sorry - I got distracted with some other work. I'm looking into this and PR13719 now. I'll let you know what I find out.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Sergei - thanks very much for the investigation. That should help me pin this down.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal>Lang.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Aug 28, 2012 at 2:33 PM, Sergei Larin <<a href="mailto:slarin@codeaurora.org" target="_blank">slarin@codeaurora.org</a>> wrote:<o:p></o:p></p><p class=MsoNormal>Andy, Lang,<br><br> Thanks for the suggestion.<br><br><br> I have spent more time with it today, and I do see some strange things in<br>liveness update. I am not at the actual cause yet, but here is what I got so<br>far:<br><br>I have the following live ranges when I start scheduling a region:<br><br>R2 = [0B,48r:0)[352r,416r:5)...<br>R3 = [0B,48r:0)[368r,416r:5)...<br>R4 = [0B,32r:0)[384r,416r:4)...<br>R5 = [0B,32r:0)[400r,416r:4)...<br><br>I schedule the following instruction (48B):<br><br>0B BB#0: derived from LLVM BB %entry<br> Live Ins: %R0 %R1 %D1 %D2<br>8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27<br>12B %vreg30<def> = LDriw <fi#-1>, 0;<br>mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30<br>20B %vreg31<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2]<br>IntRegs:%vreg31<br>24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26<br>28B %vreg106<def> = TFRI 16777216;<br>IntRegs:%vreg106<<<<<<<<<<<<<<<<<<<<<<<<<<< CurrentTop<br>32B %vreg29<def> = COPY %D2<kill>; DoubleRegs:%vreg29<br>48B %vreg28<def> = COPY %D1<kill>; DoubleRegs:%vreg28<br><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Needs to move above 28B<br>96B %vreg37<def> = LDriw <fi#-8>, 0; mem:LD4[FixedStack-8]<br>IntRegs:%vreg37<br><br>In Hexagon %D1==%R0:R1 (double reg), %D2==%R2:R3 etc.<br>The MI move triggers liveness update, which first triggers SlotIndex<br>renumbering:<br><br>*** Renumbered SlotIndexes 24-56 ***<br><br>So my 48B becomes 56B, so after the update new live ranges look like this:<br><br>R2 = [0B,56r:0)[352r,416r:5)...<br>R3 = [0B,56r:0)[368r,416r:5)...<br>R4 = [0B,48r:0)[384r,416r:4)...<br>R5 = [0B,48r:0)[400r,416r:4)...<br><br>Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also new<br>after renumbering. But happens to match another old one).<br>collectRanges for MI figures that it is moving a paired register, and<br>correctly(?) selects these two ranges to update for %R2:R3<br><br>[0B,56r:0)[368r,416r:5)...<br>[0B,56r:0)[352r,416r:5)...<br><br>___BUT____ after the update, my new ranges look like this:<br><br>R2 = [0B,32r:0)[352r,416r:5)...<br>R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have become 48r<br>R4 = [0B,48r:0)[384r,416r:4)...<br>R5 = [0B,48r:0)[400r,416r:4)...<br>....<br>0B BB#0: derived from LLVM BB %entry<br> Live Ins: %R0 %R1 %D1 %D2<br>8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27<br>12B %vreg30<def> = LDriw <fi#-1>, 0;<br>mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30<br>20B %vreg31<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2]<br>IntRegs:%vreg31<br>24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26<br>32B %vreg28<def> = COPY %D1<kill>; DoubleRegs:%vreg28<br><<<<<<<<<<<<<<<< Moved instruction<br>40B %vreg106<def> = TFRI 16777216; IntRegs:%vreg106<br>48B %vreg29<def> = COPY %D2<kill>; DoubleRegs:%vreg29<br>96B %vreg37<def> = LDriw <fi#-8>, 0; mem:LD4[FixedStack-8]<br>IntRegs:%vreg37<br><br>This is not caught at this time, and only much later, when another<br>instruction is scheduled to __the same slot___ the old one "occupied" (48B),<br>the discrepancy is caught by one of unrelated asserts... I think at that<br>time there are simply some stale aliases in liveness table.<br><br>I'm going to continue with this tomorrow, but if this helps to identify a<br>lurking bug today, my day was worth it :) :) :)<o:p></o:p></p><div><p class=MsoNormal><br>Sergei<br><br>--<br>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.<br><br><br>> -----Original Message-----<o:p></o:p></p></div><div><div><p class=MsoNormal>> From: Andrew Trick [mailto:<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>]<br>> Sent: Tuesday, August 28, 2012 3:47 PM<br>> To: Sergei Larin<br>> Cc: LLVM Developers Mailing List; Lang Hames<br>> Subject: Re: [LLVMdev] Assert in LiveInterval update<br>><br>> On Aug 28, 2012, at 8:18 AM, Sergei Larin <<a href="mailto:slarin@codeaurora.org" target="_blank">slarin@codeaurora.org</a>><br>> wrote:<br>> ><br>> > I've described that issue (see below) when you were out of town... I<br>> > think I am getting more context on it. Please take a look...<br>> ><br>> > So, in short, when the new MI scheduler performs move of an<br>> > instruction, it does something like this:<br>> ><br>> > // Move the instruction to its new location in the instruction<br>> stream.<br>> > MachineInstr *MI = SU->getInstr();<br>> ><br>> > if (IsTopNode) {<br>> > assert(SU->isTopReady() && "node still has unscheduled<br>> dependencies");<br>> > if (&*CurrentTop == MI) <<<<<<<<<<<<<<<<<< Here we<br>> make<br>> > sure that CurrentTop != MI.<br>> > CurrentTop = nextIfDebug(++CurrentTop, CurrentBottom);<br>> > else {<br>> > moveInstruction(MI, CurrentTop);<br>> > TopRPTracker.setPos(MI);<br>> > }<br>> > ...<br>> ><br>> > But in moveInstruction we use<br>> ><br>> > // Update the instruction stream.<br>> > BB->splice(InsertPos, BB, MI);<br>> ><br>> > And splice as far as I understand moves MI to the location right<br>> > __before__ InsertPos. Our previous check made sure that InsertPos !=<br>> > MI, But I do hit a case, when MI == InsertPos--, and effectively<br>> tries<br>> > to swap instruction with itself... which make live update mechanism<br>> very unhappy.<br>> ><br>> > If I am missing something in intended logic, please explain,<br>> otherwise<br>> > it looks like we need to adjust that check to make sure we never even<br>> > considering this situation (swapping with self).<br>> ><br>> > I also wonder if we want explicit check in live update with more<br>> > meaningful assert :)<br>><br>> Thanks for debugging this! The code above assumes that you're moving an<br>> unscheduled instruction, which should never be above InsertPos for top-<br>> down scheduling. If the instruction was in multiple ready Q's, then you<br>> may attempt to schedule it multiple times. You can avoid this by<br>> checking Su->isScheduled in your Strategy's pickNode. See<br>> InstructionShuffler::pickNode for an example. I don't see an equivalent<br>> check in ConvergingScheduler, but there probably should be.<br>><br>> Another possibility to consider is something strange with DebugValues,<br>> which I haven't tested much.<br>><br>> I reproduced the same assert on arm and filed PR13719. I'm not sure yet<br>> if it's exactly the same issue, but we can move the discussion there.<br>><br>> We need a better assert in live update and probably the scheduler too.<br>> Lang mentioned he may look at the issue today. Meanwhile, I hope my<br>> suggestion above helps.<br>><br>> -Andy<br><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></body></html>