On 20 March 2006 15:14, Richard Henderson wrote: > On Mon, Mar 20, 2006 at 02:56:00PM -0000, Dave Korn wrote: >> If the stack frame size is >32kB, I need to use a temporary register in >> the epilogue to assemble the lo/hi parts of the frame size before adding >> it to the SP. In the non-sibcall version of the epilogue[*] it uses one >> of the arg-passing volatiles as a scratch register, but of course in a >> sibcall epilogue that register might have been pre-loaded with an argument >> for the sibcall which we don't want to trash. So rather than get hairy >> with trying to allocate scratch regs, I was just going to refuse sibcalls >> for functions with huge stack frames. Hence my curiosity. > > Ah, interesting. In this case I'd deny sibcalls to functions that > use all of the available scratch registers for arguments.
Heh, of course, lateral thinking, attack the conflict from the opposite direction! > We do > something similar for i386 indirect sibcalls -- deny unless there's > a free register for the jump. Mmmf. In that case, of course, you absolutely /have/ to have a register available and no two ways about it. But in the direct-sibcall case, this test will generate false positives since if the stackframe is small enough I don't need a register at all and the sibcall should be ok. And I expect it to be the case that 99% of all functions /will/ have small stack frames, and so this will deny every sibcall to a function using the full set of arg passing regs when they'll almost all be ok. So I guess if I want to make the most of the opportunities for sibcalls, I still need hope that get_frame_size() is valid at F_O_F_S time and make a best-guess at the size of the frame, and if it goes from < 32k to > 32k by the time I actually come to emit the sibcall epilogue I'll just have to abort. Do you happen to know off the top of your head when get_frame_size() becomes valid? cheers, DaveK -- Can't think of a witty .sigline today....