Hello Jakob,<br><br>I think I've found something interesting that may help you get a better idea of what's going on.<br><br>While looking at the debug info I noticed that the coalescer was removing lots of copies that could help the allocator make more cross class copies. As a test, I disabled the join-liveintervals option in the coalescer which gave me the surprise of  making the regalloc succeed. To show what I mean, I'm attaching two text files that show the debug info generated when this option is enabled and disabled for my target.<br>
<br>To push things a bit further, I wrote a dirty hack in RegisterCoalescer::joinCopy() to return false when the dest regclass is too constrained. This allowed me executing the coalescer without crashing the regalloc. Obviously the generated code is not optimal at all, because there are many useless copies around. I'm pretty sure this is not the right fix at all, but it can give you a hint incase the problem is in the coalescer and not in the regalloc.<br>
<br>Thanks!<br><br><div class="gmail_quote">2012/12/18 Borja Ferrer <span dir="ltr"><<a href="mailto:borja.ferav@gmail.com" target="_blank">borja.ferav@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>Hello Jakob,<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Those are some severe constraints on register allocation, but it ought to be possible anyway.<br>

</blockquote></div><div><br>Indeed, these constraints aren't playing very well with the register allocator :\<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
You may wan't to investigate how RAGreedy::canEvictInterference() is behaving.<span><font color="#888888"><br></font></span></blockquote></div><div><br>Ok, this is what I've noticed, not sure if it makes sense at all but, regalloc fails with the following sequence:<br>

<br>1) directly assign the physreg in PTR RC to a virtX.<br>2) for a virtY which also belongs to the PTR RC, try to evict: call canEvictInterference() for virtY which interferes with virtX, returns true. evict and unassign virtX and assign physreg to virtY.<br>

3) for a virtZ which also belongs to the PTR RC, try to evict: call 
canEvictInterference() for virtZ which interferes with virtY, both VirtReg.isSpillable() and Intf->isSpillable() return false, can't evict, wait for a second round and queue new interval.<br>4) do some work unrelated to these vregs.<br>

5) when selectOrSplit is called again for virtZ it falls through down to the return ~0u line and fails.<br><br><br>This issue can be very easily reproduced with the Thumb2 target by doing the following few changes:<br><br>

1) declare a PTRRC regclass in ARMRegisterInfo.td with only one physreg:<br>def PTRRC : RegisterClass<"ARM", [i32], 32, (add R6)>;<br><br>2) modify the RC used in the addr_offset_none addressing mode in ARMInstrInfo.td around line 947 to:<br>

  let MIOperandInfo = (ops PTRRC:$base);<br>(this is used by the t2LDR_POST instruction)<br><br>3) and likewise modify the t2addrmode_imm12 addressing mode in ARMInstrThumb2.td around line 151 to:<br>let MIOperandInfo = (ops PTRRC:$base, i32imm:$offsimm);<br>

(used by the load/store instructions)<br> <br>then compile with -O3 and done :)<br><br>In addition, I've attached the debugging info generated by the regalloc for the Thumb2 target. The main difference of the debug output using my target is that I didn't get any spill code like Thumb2 has, probably because i have far more free regs available.<br>

<br>Thanks for your help.<br><br></div></div>
</blockquote></div><br>