[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