[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

[John Mosby]

On Tue, Aug 11, 2009 at 11:46 PM, Evan Cheng <evan.cheng at apple.com> wrote:

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


I'm not considering shrink wrapping at the moment, so CalleeSavedInfo,
when available (after the CSR scan done near the beginning of PEI) should
be all that is needed. Would making this information a prerequisite for RS
limit the clients of RS? I'm just thinking in terms of extending the use of
RS
within PEI, but there could be other users.

We could also have RS use the info when it's available.

With shrink wrapping, if we do what Jakob is suggesting and add the unused
CSRs to the live-in lists of all MBBs, the live-in info should be correct
when
they are spilled.

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?


Very clearly stated, thanks. I am trying to get to a point where we can
just get a register and have it be spilled/restored if necessary, full stop.
If the MBB live-in info can be kept accurate, RS clients will not have to
worry about spills/restores, they can just use the regs RS gives them.

The code I am working on in PEI recomputes the frame if new CSRs
are used by RS, adding spill slots as necessary.
For shrink wrapping, once the used CSRs are known, it can run as usual.
The used CSR info will be complete after all the virtual regs have been
assigned.

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