[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]

On 13/08/2009, at 08.40, Evan Cheng wrote:

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

We may have been pulling in different directions here. I was in bugfix  
mode, wanting the scavenger to be correct and more robust before  
adding features. That's over now.

The scavenger now has an accurate idea of the registers immediately  
available. I don't think the client has anything useful to add to  
that, so I would like to remove the 'Candidates' argument to  
FindUnusedReg(). I can't think of a reason why the client would  
restrict the search beyond the desired register class.

Now, we want to scavenge pristine CSRs by spilling them in the  
prologue. With the information currently in MachineFrameInfo,  
scavengeRegister() should be able to determine if such a register  
exists. Since PEI created the original spills, it makes sense to me to  
ask PEI to insert the additional spills as well.

Do we need to involve the client? Only if there are target-specific  
considerations. Anybody know some examples?

/jakob