Hi Jakob,<div><br></div><div>Could you please not commit this for the moment.   I've noticed that the spill weights for some phys regs are not infinite.  If I force the weight to be infinite (as it should always be for phys regs?) with a debugger then it avoids findIntervalsToSpill completely.  Looks like the root of the bug is elsewhere.</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>Thanks, Krister</div><div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Dec 15, 2010 at 1:06 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On Dec 14, 2010, at 7:25 PM, Krister Wombell wrote:<br>
<br>
> I've come across a bug in RALinScan::assignRegOrStackSlotAtInterval that occurs when:<br>
><br>
> - an interval conflicts with all physical registers in it's class<br>
> - and one of the phys regs has a lower spill weight then the interval being assigned<br>
> - and there are no active or inactive intervals (or no entries of an overlapping reg class)<br>
><br>
> findIntervalsToSplit then runs but won't be able to find the best candidate as it fails to find a anything suitable in the 'active_' or 'inactive_' lists. The code asserts that there's nothing to spill.<br>

><br>
> It's a fairly obscure set of circumstances but can happen if there is a register class with no callee saved registers and a call instruction (that implicitly defines all registers in that class).  It (probably?) also requires that the interval being assigned is itself the result of spilling as both the spill weight needs to be quite high.<br>

><br>
> I've attached a fix that spills the current interval if findIntervalsToSplit returns nothing.<br>
<br>
</div>It looks reasonable, do you have a test case?<br>
<font color="#888888"><br>
/jakob<br>
<br>
</font></blockquote></div><br></div></div>