Richard Earnshaw wrote:
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).
Do you have anything in mind that would be a better default? Is there something that could be used instead of hard_frame_pointer_rtx that will later expand to the correct frame address, but not necessarily force use of a frame pointer, for example? (As far as I can tell, frame_pointer_rtx will not do at least in the ARM case, because it doesn't yield the same value.) If the hard frame pointer is forced by default, then targets which are particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX. Since such targets would presumably not have to force reload to keep the frame pointer, then definitions of such macros would not need to be side-effecting (in the way described earlier in this thread) and thus be satisfactory.
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.
Currently, the code does require a frame pointer in all except the count == 0 case, and as far as that particular case goes I get the impression that it would have been treated in the same way had this glibc backtrace function been noticed last year. This may be a mistaken impression though. Mark
