On Thu, 2006-06-01 at 16:05, Mark Shinwell wrote: > Mark Mitchell wrote: > > Mark Shinwell wrote: > >> As for the remaining problem, I suggest that we could: > >> > >> (i) always return the hard frame pointer, and disable FP elimination in > >> the current function; or > >> > >> (iii) ...the same as option (i), but allow targets to define another macro > >> that will cause the default code to use the soft frame pointer rather than > >> the hard frame pointer, and hence allow FP elimination. (If such a macro > >> were set by a particular target, am I right in thinking that it would be > >> safe to use the soft frame pointer even in the count >= 1 cases?) > > > >> I tend to think that option (iii) might be best, although perhaps it > >> is overkill and option (i) would do. But I'm not entirely sure; > >> still being a gcc novice I have to admit to not being quite thoroughly > >> clear on this myself at this stage. So any advice or comments would be > >> appreciated! > > > > I agree that option (iii) is best, as it provides the ability to > > optimize on platforms where that is feasible, and still provides a > > working default elsewhere. I will review and approve a suitable patch > > to implement (iii), assuming that there are no objections from Jim or > > others. > > This having been discussed some more, and my understanding improved, > I now believe that option (i) is in fact the correct thing to do. The > attach patch implements this, which basically amounts to the same logic > that is currently in the compiler save for the removal of the special > case when count == 0. > > OK for mainline? >
I'm not keen on this. On some machines a frame pointer is *very* expensive, both in terms of the code required to set it up, and the resulting loss of a register which affects code quality (in addition, on Thumb, the frame pointer can access much less data on the stack than the stack pointer can, so code quality is affected even more). I can see no argument for a frame pointer being *required* for getting the return address. We didn't have to do this in the past, so I think it is wrong to require that we do it now. R. > Mark > > -- > > 2006-06-01 Mark Shinwell <[EMAIL PROTECTED]> > > * gcc/builtins.c (expand_builtin_return_addr): Always use > hard_frame_pointer_rtx and prevent frame pointer elimination > if INITIAL_FRAME_ADDRESS_RTX isn't set.