[LLVMdev] Shrink Wrapping - RFC and initial implementation

John Mosby ojomojo at gmail.com
Mon Mar 2 20:21:58 PST 2009


On Mon, Mar 2, 2009 at 10:35 AM, Evan Cheng <echeng at apple.com> wrote:

>
> On Mar 1, 2009, at 2:57 PM, John Mosby wrote:
>
> Obviously, all of this applies only when spills are done with push/pop,
> which is the case on x86. I used this issue to start looking at generalizing
> how spills and restores are handled, before looking too closely at other
> targets, and developed the workaround for the initial implementation.
>
>
> Spills don't have to be done with push and pop. One possible approach to
> take is to perform them with store and load. Then later on PEI will optimize
> (some of) them into push and pop.
>

I am rewriting to use stores/loads via storeRegToStackSlot(),
loadRegFromStackSlot(), which will obviate the stack adjustment. I did it
this way in an early version, but the architecture is to give the target a
chance to generate the spill(restore) code itself, so I conformed to that.
As you point out, these can selectively be replaced with push/pop later.


> Part of what I'm doing now is estimating the work, which requires going
> through the targets. I am not far enough along to send out a proposal.
> Moving pro/epi generation out of TRI, perhaps into its own "component" is
> one architecture I am looking at.
>
>
> It's not necessary to update all the targets at once. We can ask targets to
> opt in to take advantage of shrink wrapping.
>

That sounds good. I now have a better handle on the differences between the
targets: XCore handles frame moves in its spillCalleeSavedRegister(), the
ARM code for this is very straightforward.

I hope to have an updated patch done tomorrow, with doc. and explicated
examples.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090302/aa079857/attachment.html>


More information about the llvm-dev mailing list