<br><br><div class="gmail_quote">On Mon, Mar 2, 2009 at 10:35 AM, Evan Cheng <span dir="ltr"><<a href="mailto:echeng@apple.com">echeng@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="Ih2E3d"><div>On Mar 1, 2009, at 2:57 PM, John Mosby wrote:</div><br></div></div><div><div class="Ih2E3d"><blockquote type="cite"><div class="gmail_quote"><div>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.</div>
</div></blockquote></div></div><div><div class="Ih2E3d"><div><br></div></div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div>As you point out, these can selectively be replaced with push/pop later.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">
<div></div><div><div class="Ih2E3d"><blockquote type="cite"><div class="gmail_quote"><div>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.</div>
</div></blockquote><div><br></div></div>It's not necessary to update all the targets at once. We can ask targets to opt in to take advantage of shrink wrapping.</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>I hope to have an updated patch done tomorrow, with doc. and explicated examples.</div><div><br></div><div>Thanks,</div><div>John</div><div><br></div><div> </div></div>