Hi Arnaud,<div><div class="gmail_quote"><div><br></div><div>The patch looks good. I've committed it in r133249.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="blue"><div><p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font></p>
<p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">I noticed an unexpected --- to me at least --- behaviour of the allocator.</span></font></p>
<p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">I have some instructions using 2 pairs of registers, say “mpra R_x, R_x+1, R_y, R_y+1”, and setting the pairing constraints R_x -> R_x+1
 and R_y -> R_y+1 could silently produce wrong code like “mpra %R0, %R2, %R1, %R3”. I add to explicitly add another constraint  to describe that y must differ from x, x-1 and x+1 to make the allocator build valid pairs, i.e “mpra %R0, %R1, %R2, %R3”. Is there
 anything I missed ?</span></font></p>
<p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"></span></font></p></div></div></blockquote><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
Hmm. Let me make sure I'm reading this right. The constraints are that:<br>a) All four operands have distinct registers.</div><div>b) The first two are in a consecutive pair (second > first)</div><div>c) The second two are in a consecutive pair (fourth > third)</div>
<div><br></div><div>If that's accurate then you will need four constraints to represent it. Two to enforce the pairing, which you've already described, and two to enforce the distinction. Without constraint enforcing the R_x != R_y distinction the PBQP allocator is free to allocate <font class="Apple-style-span" face="'courier new', monospace">mpra %R0, %R1, %R0, %R1</font>. You'll also need (R_x+1 != R_y) to ensure that you don't get something like <font class="Apple-style-span" face="'courier new', monospace">mpra %R0, %R1, %R1, %R2</font>. </div>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div lang="EN-US" link="blue" vlink="blue"><div></div></div></blockquote></div><div> </div><div>That said my understanding of your pairing constraints would definitely prohibit <span class="Apple-style-span" style="font-family: Arial; font-size: 13px; ">mpra %R0, %R2, %R1, %R3 under any circumstances, even with out the distinction constraint. Either I've misunderstood your constraints, or there is a bug somewhere.</span></div>
<div><span class="Apple-style-span" style="color: rgb(0, 0, 128); font-family: Arial; font-size: 13px; "> </span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="blue"><div>
<p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Now, 99% of my users’ codebase is compiling.
</span></font><font size="2" color="navy" face="Wingdings"><span style="font-size:10.0pt;font-family:Wingdings;color:navy">J</span></font><font size="2" color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"></span></font></p>




<p class="MsoNormal"><font size="2" color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">The last issue I have is an assert during regalloc in LiveIntervalAnalysis : “attempt to spill already spilled interval!”, and I do not
 know where to start looking. Any hint would be welcome.</span></font></p>
<div>
<p class="MsoNormal"><font size="2" color="navy" face="Courier New"><span style="font-size:10.0pt;font-family:"Courier New";color:navy"></span></font></p></div></div></div></blockquote><div><br></div><div>The data structure you want to keep your eye on is the set <font class="Apple-style-span" face="'courier new', monospace">vregsToAlloc</font> to RegAllocPBQP. This set holds the virtual registers which PBQP must allocate for on its next round. Once a virtual register has been spilled it should be erased from this set (see <font class="Apple-style-span" face="'courier new', monospace">RegAllocPBQP::mapPBQPToRegAlloc</font>), and it should never re-enter it, and thus never be considered again by the PBQP allocator. At a guess it sounds like one of your vregs may be being added to this set a 2nd time, but I'm not sure how that could be happening.</div>
<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8">Is your backend public? Are you able to share a test case with me? I'm very busy with my PhD write-up at the moment, but I will try to find time for a quick look at this.</div>
<div><br></div><div>Regards,</div><div>Lang.</div><div><br></div></div></div>