[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

Jakob Stoklund Olesen stoklund at 2pi.dk
Tue Aug 11 12:17:33 PDT 2009


On 11/08/2009, at 09.20, Evan Cheng wrote:
>
> Thanks Jakob. Since you are hacking on this, perhaps you can help me
> clean it up further? :-)

Sure.

> I think we need to completely do away with
> DistanceMap. I think using it is a very bad idea.
>
> Or rather findFirstUse() is a bad idea. It's using MachineRegisterInfo
> to iterate over uses of *physical* registers. That's incredibly
> expensive since the number of uses in a large function can be very  
> big.
>
> I think a better solution is perhaps something like this. First create
> a set of all candidates. Then iterate over the next N instructions
> (where N is reasonable number of instructions, perhaps something like
> 10?) and calculate the distance of the closest use (and use of any
> alias). This is not a great solution but it would avoid the really bad
> pathological case.

I was thinking along similar lines, and I will be happy to code it up,  
but an issue must be addressed first: The scavengeRegister() function  
may find an unused CSR, and it is not always clear how to handle it.  
That can happen for one of two reasons: 1) The CSR has been saved in  
the prologue and happens to be unused at this point, or 2) The CSR has  
not been spilled because it is not used in the function.

In the first case, the CSR can be used directly without being saved.  
In the second case, it must be saved. If the CSR is used later in the  
MBB, the scavenger assumes the first case. If it isn't used anymore in  
the MBB, we assume the second case and mark the CSR live before  
spilling it.

This procedure causes trouble if we no longer scan all the way to the  
end of the MBB. Suppose we assume that the CSR must be spilled if it  
isn't used in the next 10 instructions as Evan suggests. We spill and  
restore 10 instructions later, but now we leave the CSR live when it  
was dead before. This leads to trouble if we were mistaken and the CSR  
is really used 20 instructions down.

How do we handle this? Before CSR spill code is inserted, we should  
leave CSRs marked as available, and the scavenger should be free to  
use them without spilling first. After CSR spill code is inserted, all  
the remaining CSRs should be marked live-in to every MBB in the  
function. That's what they are after all. If we do that, the scavenger  
will be able to use these register without any special handling. It  
can see that the free CSR is in use, and it will make sure to spill it  
to the emergency spill slot.

John, what do you think? What are your plans regarding CSRs and the  
scavenger?

/jakob






More information about the llvm-commits mailing list