[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

[Evan Cheng]

On Aug 12, 2009, at 6:51 PM, John Mosby wrote:

> 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.

We can iterate on it. It doesn't have to be totally right the first  
time.

>
> 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.

I am not exactly certain what's the *right* approach. But Jakob was  
right that scavengeRegister() would leave the instruction stream in a  
correct state. That means RS should handle the spilling and restoring.  
However, we should allow for the option for the client to handle it  
better.

>
> > 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.

Ok.

>
> 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.

Sounds good.

Evan

>
> Cheers,
> John
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090812/6db5ec0c/attachment.html>