On 21 March 2006 14:58, Richard Henderson wrote: > On Mon, Mar 20, 2006 at 04:03:08PM -0000, Dave Korn wrote: >> Do you happen to know off the top of your head when get_frame_size() >> becomes valid? > > You don't get a good first-pass estimate until after all rtl > generation has been done. Which is later than you need.
Absolutely. Right. > Another possibility is to allocate an extra word high in the > stack frame for temporary storage in large frames w/ sibcalls > to functions using all arguments. Then you'd deallocate in > several steps: > > scratchslot = argument > argument = stack frame size - small > sp += argument > argument = scratchslot > sp += small Yeh, I'd thought about that. I reckon it's probably a better solution than aborting. I'll just make sure and handle all kinds of sibcalls. Like I said, my original question was inspired by wanting to make a quick first pass at it that would just opt out from doing the hard cases, and it seems that it's easier to take care of them than to try and detect them in order to forbid sibcalls in those large-framed functions. > This scheme has the advantage that you don't need to commit > to it until the last minute. Don't forget that you can also > handle "small" large values in a small number of steps. E.g. > for 65k: > > sp += 32764 > sp += 32764 > sp += 1032 > > Which may well be faster than going through memory as above. > Of course, you wouldn't want to use this scheme for a 2mb frame. On my small embedded target, if I ever have a 2mb frame, I'm gonna be in a whole lot more trouble than just taking a few dozen insns to unwind it! I'm only making sure that >32k stack frames work /at all/ as a contingency! cheers, Dave '32k should be enough for anybody' K -- Can't think of a witty .sigline today....