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