Mark Shinwell wrote: > Hi, > > I'd like to gather some opinions and advice on the expansion of > __builtin_frame_address, as discussed on gcc-patches last year [1, 2]. > This centres on the following comment in expand_builtin_return_addr > arising from revision 103294 last year:
I've explicitly Cc'd Jim Wilson on this email, since he did the work in this area that you cite. I'm not sure whether Jim is reading GCC email presently or not, but I want to give him every opportunity to comment. > Let us come back to the more general case. As identified above, when > expand_builtin_return_addr is used to expand __builtin_frame_address (), > we do care about the count == 0 case. I believe that the comment should > be adjusted to reflect this whatever other changes, if any, are made. I think this is non-controversial. > 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. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
