Re: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-20 Thread Richard Henderson
On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote: > So, what if the decision it needs to make depends on the stack frame > size of the current function? How can this possibly be? When the sibcall is done, the current function's stack frame is removed. r~

RE: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-20 Thread Dave Korn
On 20 March 2006 14:45, Richard Henderson wrote: Hi Richard :) > On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote: >> So, what if the decision it needs to make depends on the stack frame >> size of the current function? > > How can this possibly be? When the sibcall is done, the cu

Re: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-20 Thread Richard Henderson
On Mon, Mar 20, 2006 at 02:56:00PM -, 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-p

RE: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-20 Thread Dave Korn
On 20 March 2006 15:14, Richard Henderson wrote: > On Mon, Mar 20, 2006 at 02:56:00PM -, 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-sibcal

Re: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-21 Thread Richard Henderson
On Mon, Mar 20, 2006 at 04:03:08PM -, 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. Another possibility is to allo

Re: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-21 Thread Paul Brook
On Tuesday 21 March 2006 14:57, Richard Henderson wrote: > On Mon, Mar 20, 2006 at 04:03:08PM -, 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 d

RE: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-21 Thread Dave Korn
On 21 March 2006 15:12, Paul Brook wrote: > On Tuesday 21 March 2006 14:57, Richard Henderson wrote: >> On Mon, Mar 20, 2006 at 04:03:08PM -, 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 est

RE: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-21 Thread Dave Korn
On 21 March 2006 14:58, Richard Henderson wrote: > On Mon, Mar 20, 2006 at 04:03:08PM -, 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. Wh

Re: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET

2006-03-21 Thread Paul Brook
> >>scratchslot = argument > >>argument = stack frame size - small > >>sp += argument > >>argument = scratchslot > >>sp += small > > > > This assumes you have a frame pointer or sp+large_offset addressing mode > > for accessing scratchslot. In which case you could either use fp