[llvm-commits] [llvm] r78650 - in /llvm/trunk: include/llvm/CodeGen/RegisterScavenging.h lib/CodeGen/RegisterScavenging.cpp test/CodeGen/Blackfin/2009-08-11-RegScavenger-CSR.ll

[John Mosby]

On Wed, Aug 12, 2009 at 7:12 PM, Evan Cheng <evan.cheng at apple.com> wrote:

>
> On Aug 12, 2009, at 12:24 PM, Jakob Stoklund Olesen wrote:
>
> > ARM currently tries to predict RS usage and make PEI spill an extra
> > register. That is one approach. Another is a target callback to amend
> > the prologue. A third would be to rerun PEI somehow. I am not sure
> > which is better.
>
> If the target that uses RS wants to be smart, then it should something
> like what ARM is doing. To me, RS's job is not that. It should just
> make sure it's correct. That means either a target callback or
> returning a set of CSRs which need to be spilled. The client should be
> responsible for figuring out the best way to handle the information.


Evan is right about this, but still don't know if a target callback is the
best way.
Then again it might be necessary.

I am essentially having RS return a set of CSRs needing spills in allocating
registers in the new PEI, and I am partially re-running PEI when the reg
alloc
requires additional spills.


> > This is interesting. We have two dimensions: useless/usable and
> > precious/garbage. The scavenger cares about the precious/garbage axis
> > because it wants to avoid clobbering anything precious. The verifier
> > should probably care about both.
>
> I agree there is a fine distinction between all these different ways
> of looking at unused CSRs. But the fact is we don't know what's in
> these registers. It could be the caller doesn't actually care about
> these CSRs. When RS is saving a CSR, I'd suggest just mark the
> register undef to play nice with liveness computation. It's ok for
> machine verifier to treat them as MBB liveins if you want to catch
> this class of bugs.
>
> >
> > You say "Let's ignore shrink wrapping". Can I break it even more? If I
> > allow the scavenger to use spilled CSRs without proper per-MBB CSR
> > tracking, it can lead to clobbered CSRs under shrink wrapping. ARM
> > does that today, I think.
>
> Right. I think it's a fixable problem. Basically, this means these
> CSRs can only be used in certain blocks. For now, we can just say
> shrink wrapping is only useable if RS is not used by the target. John,
> what do you think?


That's the best way to proceed at this point. We can tackle shrink
wrapping later. When spills/restores are placed in shrink wrapping,
we at least know the regions in the MCFG over which each CSR
used in the function is spilled/restored.

BTW, my plan is to move shrink wrapping to the end of PEI after all uses
of RS to allocate registers and after the frame has been reconstructed
if additional CSRs are used. The set of CSRs used in the function will
then be complete and spills/restores can be generated and shrink wrapped
(or not) as before. Let me know if this sounds ok.

Cheers,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090812/b56df51e/attachment.html>