<div class="gmail_quote">On Tue, Aug 11, 2009 at 11:46 PM, Evan Cheng <span dir="ltr"><<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>> I was thinking along similar lines, and I will be happy to code it 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 has<br>
> not been spilled because it is not used in the function.<br>
<br>
</div></div>Ok. There is sufficient information to distinguish the two cases, right?</blockquote><div><br></div><div>I'm not considering shrink wrapping at the moment, so CalleeSavedInfo,</div><div>when available (after the CSR scan done near the beginning of PEI) should</div>
<div>be all that is needed. Would making this information a prerequisite for RS</div><div>limit the clients of RS? I'm just thinking in terms of extending the use of RS</div><div>within PEI, but there could be other users.</div>
<div><br></div><div>We could also have RS use the info when it's available.</div><div><br></div><div>With shrink wrapping, if we do what Jakob is suggesting and add the unused</div><div>CSRs to the live-in lists of all MBBs, the live-in info should be correct when</div>
<div>they are spilled.</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">That's probably a reasonable step in the right direction. But let's</div>

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 well.<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>
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?</blockquote><div><br></div><div>Very clearly stated, thanks. I am trying to get to a point where we can</div><div>just get a register and have it be spilled/restored if necessary, full stop.</div><div>
If the MBB live-in info can be kept accurate, RS clients will not have to</div><div>worry about spills/restores, they can just use the regs RS gives them.</div><div><br></div><div>The code I am working on in PEI recomputes the frame if new CSRs</div>
<div>are used by RS, adding spill slots as necessary.</div><div>For shrink wrapping, once the used CSRs are known, it can run as usual.</div><div>The used CSR info will be complete after all the virtual regs have been assigned.</div>
<div><br></div><div>John</div></div>