<div class="gmail_quote">On Wed, Aug 12, 2009 at 7:12 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>
On Aug 12, 2009, at 12:24 PM, Jakob Stoklund Olesen wrote:<br>
<br></div></div><div class="im">
> ARM currently tries to predict RS usage and make PEI spill an extra<br>
> register. That is one approach. Another is a target callback to amend<br>
> the prologue. A third would be to rerun PEI somehow. I am not sure<br>
> which is better.<br>
<br>
</div>If the target that uses RS wants to be smart, then it should something<br>
like what ARM is doing. To me, RS's job is not that. It should just<br>
make sure it's correct. That means either a target callback or<br>
returning a set of CSRs which need to be spilled. The client should be<br>
responsible for figuring out the best way to handle the information.</blockquote><div><br></div><div>Evan is right about this, but still don't know if a target callback is the best way.</div><div>Then again it might be necessary.</div>
<div><br></div><div>I am essentially having RS return a set of CSRs needing spills in allocating</div><div>registers in the new PEI, and I am partially re-running PEI when the reg alloc</div><div>requires additional spills.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">> This is interesting. We have two dimensions: useless/usable and<br>
> precious/garbage. The scavenger cares about the precious/garbage axis<br>
> because it wants to avoid clobbering anything precious. The verifier<br>
> should probably care about both.<br>
<br>
</div></div>I agree there is a fine distinction between all these different ways<br>
of looking at unused CSRs. But the fact is we don't know what's in<br>
these registers. It could be the caller doesn't actually care about<br>
these CSRs. When RS is saving a CSR, I'd suggest just mark the<br>
register undef to play nice with liveness computation. It's ok for<br>
machine verifier to treat them as MBB liveins if you want to catch<br>
this class of bugs.<br>
<div class="im"><br>
><br>
> You say "Let's ignore shrink wrapping". Can I break it even more? If I<br>
> allow the scavenger to use spilled CSRs without proper per-MBB CSR<br>
> tracking, it can lead to clobbered CSRs under shrink wrapping. ARM<br>
> does that today, I think.<br>
<br>
</div>Right. I think it's a fixable problem. Basically, this means these<br>
CSRs can only be used in certain blocks. For now, we can just say<br>
shrink wrapping is only useable if RS is not used by the target. John,<br>
what do you think?</blockquote><div><br></div><div>That's the best way to proceed at this point. We can tackle shrink</div><div>wrapping later. When spills/restores are placed in shrink wrapping,</div><div>we at least know the regions in the MCFG over which each CSR</div>
<div>used in the function is spilled/restored.</div><div><br></div><div>BTW, my plan is to move shrink wrapping to the end of PEI after all uses</div><div>of RS to allocate registers and after the frame has been reconstructed</div>
<div>if additional CSRs are used. The set of CSRs used in the function will</div><div>then be complete and spills/restores can be generated and shrink wrapped</div><div>(or not) as before. Let me know if this sounds ok.</div>
<div><br></div><div>Cheers,</div><div>John</div><div><br></div></div>