<div class="gmail_quote">On Wed, Aug 12, 2009 at 1:04 AM, 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 12/08/2009, at 07.46, Evan Cheng wrote:<br>
<br>
><br>
> On Aug 11, 2009, at 12:17 PM, Jakob Stoklund Olesen wrote:<br>
>><br>
</div><div class="im">>> I was thinking along similar lines, and I will be happy to code it<br>
>> up,<br>
>> but an issue must be addressed first: The scavengeRegister() function<br>
>> may find an unused CSR, and it is not always clear how to handle it.<br>
>> That can happen for one of two reasons: 1) The CSR has been saved in<br>
>> the prologue and happens to be unused at this point, or 2) The CSR<br>
>> has<br>
>> not been spilled because it is not used in the function.<br>
><br>
> Ok. There is sufficient information to distinguish the two cases,<br>
> right?<br>
<br>
</div>Not really. The current code is quite fragile but errs on the safe<br>
side. It only clobbers the CSR if it isn't used any more in the MBB.<br>
<br>
We could use CalleeSavedInfo, but that is not very accurate when<br>
shrink wrapping is used.</blockquote><div><br></div><div>Seems like it has to be pushed down to the MBB... </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
We can detect 3) PEI has not inserted CSR spills yet. Then<br>
CalleeSavedInfo will be empty.</blockquote><div><br></div><div>CalleeSavedInfo just says which CSRs are used in at least one</div><div>MBB in a function. It assumes all used CSRs will be spilled in</div><div>entry and restored in return blocks.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">>> In the first case, the CSR can be used directly without being saved.<br>
>> In the second case, it must be saved. If the CSR is used later in the<br>
>> MBB, the scavenger assumes the first case. If it isn't used anymore<br>
>> in<br>
>> the MBB, we assume the second case and mark the CSR live before<br>
>> spilling it.<br>
><br>
> My preference is to let the client of the scavenger to be responsible<br>
> for handling these details.<br>
<br>
</div>I am not sure that is a good idea. We are distributing the handling of<br>
CSRs among three parties: PEI, scavenger, and the target.<br>
<br>
Blackfin uses this code whenever it needs a register:<br>
<br>
unsigned Reg = RS->FindUnusedReg(RC, true);<br>
if (Reg == 0)<br>
Reg = RS->scavengeRegister(RC, II, SPAdj);<br>
<br>
It is completely clueless, it just wants a register. Only ARM seems to<br>
do something different.</blockquote><div><br></div><div>Actually ARM does that also.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I would prefer to let PEI provide accurate live-in lists, let the<br>
scavenger track available registers accurately based on that info, and<br>
let the client simply ask for a register without worrying about which<br>
CSRs are spilled at this exact instance.</blockquote><div><br></div><div>I agree</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">[...]<br>
<div class="im"><br>
>> How do we handle this? Before CSR spill code is inserted, we should<br>
>> leave CSRs marked as available, and the scavenger should be free to<br>
>> use them without spilling first. After CSR spill code is inserted,<br>
>> all<br>
><br>
> Right. PEI should spill them later.<br>
><br>
>> the remaining CSRs should be marked live-in to every MBB in the<br>
>> function. That's what they are after all. If we do that, the<br>
>> scavenger<br>
><br>
> We shouldn't be introducing them as livein to MBBs. Do you mean the<br>
> scavenger should treat them as if they are livein?<br>
<br>
</div>Actually, I want to add them to the live-in lists. That way, the<br>
machine code verifier will also be able to detect clobbered CSRs.<br>
<br>
PEI is already doing this with spilled CSRs, is there a downside to<br>
doing it?</blockquote><div><br></div><div>I agree with Jakob on this. Is it that there needs to be a more general</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> will be able to use these register without any special handling. It<br>
>> can see that the free CSR is in use, and it will make sure to spill<br>
>> it<br>
>> to the emergency spill slot.<br>
><br>
> That's probably a reasonable step in the right direction. But let's<br>
> expand on this a bit. I see the following scenarios:<br>
><br>
> 1. Scavenger is used before PEI has saved callee-saved registers. All<br>
> that scavenger has to do is to mark the scavenged callee-saved<br>
> register as being used. Later on, PEI will save the CSR and all is<br>
> well.<br>
<br>
</div>Yep.<br>
<div class="im"><br>
> 2. If it is used after CSR are spilled, and the chosen CSR has already<br>
> been spilled. There is nothing to do.<br>
<br>
</div>Yes, but the scavenger needs a safe way of detecting this situation,<br>
even with shrink wrapping enabled.</blockquote><div><br></div><div>With shrink wrapping, you need to know where a given CSR is spilled, i.e.</div><div>the region in which it is spilled/restored, which is no longer the entire function.</div>
<div><br></div><div>What I plan to do, not yet implementing it, is allocate all regs in one pass of</div><div>PEI, possibly introducing new CSR uses requiring spills, recompute the frame,</div><div>then place the spills and restores (shrink wrap). This way there is no need to</div>
<div>keep track of whether or not a CSR has been spilled yet.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> 3. If it is used after CSR are spilled, and the chosen CSR has not<br>
> been spilled. This is the only real messy case.<br>
> 3a. Treat it as if a scavenged register. That is, spill to the<br>
> emergency slot and restore it after it has been used. This is<br>
> basically what you described.<br>
> 3b. The client should be informed a new CSR is used. It is<br>
> responsible for modifying the prologue and epilogue. I believe this is<br>
> the preferred solution. Of course, a client that's not capable of<br>
> modifying the prologue should not do this.<br>
><br>
> What do you think?<br>
<br>
</div>We could add a TRI->modifyPrologueAndEpilogue() callback, except with<br>
a better name. If it returns true, we can go ahead and use the CSR. If<br>
it returns false, we use the emergency slot.<br>
<br>
Either the scavenger or the target needs to make sure this callback is<br>
only called once per CSR per MBB.</blockquote><div><br></div><div>That sounds fine to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Right now, the scavenger is tracking certain CSRs as available, but it<br>
is not allowed to use them. That looks like a clobbered CSR just<br>
waiting to happen. These poison CSRs should be marked as used when<br>
entering the MBB. It does not /have/ to be done through the live-in<br>
lists - that just seems like a natural choice.</blockquote><div><br></div><div>I committed an RS patch to this effect, but Evan backed it out. I don't see</div><div>CSR clobbering possible, what am I missing here?</div>
<div>Do you mean using FindUnusedReg() with ExCalleeSaved=false? (sorry, it's late)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Whatever we do, the scavenger and the machine code verifier should<br>
agree on the method.</blockquote><div><br></div><div>Certainly.</div><div><br></div><div>John</div></div>