[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 11, 2009, at 12:17 PM, Jakob Stoklund Olesen wrote:

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

Ok. There is sufficient information to distinguish the two cases, right?

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

My preference is to let the client of the scavenger to be responsible  
for handling these details.


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

Right. PEI should spill them later.

> 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

We shouldn't be introducing them as livein to MBBs. Do you mean the  
scavenger should treat them as if they are livein?


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

That's probably a reasonable step in the right direction. But let's  
expand on this a bit. I see the following scenarios:

1. Scavenger is used before PEI has saved callee-saved registers. All  
that scavenger has to do is to mark the scavenged callee-saved  
register as being used. Later on, PEI will save the CSR and all is well.
2. If it is used after CSR are spilled, and the chosen CSR has already  
been spilled. There is nothing to do.
3. If it is used after CSR are spilled, and the chosen CSR has not  
been spilled. This is the only real messy case.
    3a. Treat it as if a scavenged register. That is, spill to the  
emergency slot and restore it after it has been used. This is  
basically what you described.
    3b. The client should be informed a new CSR is used. It is  
responsible for modifying the prologue and epilogue. I believe this is  
the preferred solution. Of course, a client that's not capable of  
modifying the prologue should not do this.

What do you think?

Evan

>
> John, what do you think? What are your plans regarding CSRs and the
> scavenger?
>
> /jakob
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits