Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86

["H.J. Lu" <hjl dot tools at gmail dot com>]

Hi Mark,

Thanks for your inputs.

On Tue, Aug 3, 2010 at 10:12 AM, Mark Mitchell <mark@codesourcery.com> wrote:
> Mark Mitchell wrote:
>
>> I will review the thread today. ?Please give me some time to comment.
>
> I can certainly see both sides of this issue.
>
> On the one hand, most users use "-O2" or "-O3", and we want those users
> to see the best performance possible. ?It's not reasonable to expect
> that most users will figure out that they can use -fomit-frame-pointer
> to improve performance and add it in. ?My understanding is that some
> distributions (e.g., OpenSuSE, IIUC) are now building the vast majority
> of the distribution with -fomit-frame-pointer, but end users will not
> necessarily know that they can/should use this option. ?The bottom line
> is that -O2 should maximize performance.
>
> On the other, changing this default will undoubtedly cause pain. ?As
> Daniel said, we know that ARM and MIPS users have wrestled with the lack
> of a frame pointer for some time. ?There is a surprising amount of code
> that has built-in unwinders of various kinds. ?Being able to get
> accurate backtraces from systems deployed in the field is essential for
> many users. ?This code will break, silently, and people will be unhappy.
>
> If I could, I'd go back in time and eliminate ABIs that use frame
> pointers. ?The use of unwind tables is, IMHO, a clearly superior

Just for the reference, this is from i386 psABI:

---
%ebp  The frame pointer optionally holds a base address for the current
           stack frame. Consequently, a function has registers pointing to
           both ends of its frame. Incoming arguments reside in the previous
           frame, referenced as positive offsets from %ebp, while local
           variables reside in the current frame, referenced as negative
           offsets from %ebp. A function must preserve this register’s value
           for its caller.
---

The stack layout at function entry is the same as x86-64 psABI. I understand
the old backtrace codes depend on the frame pointer, but it isn't mandated
by the psABI.

> solution. ?It provides for superior performance, and, for users
> uninterested in backtraces, smaller code. ?(Even for users who do need
> backtraces, it may result in a smaller cache footprint, since the unwind
> tables will remain paged out most of the time.) ?But, we are where we
> are, and we can't go back. ?So, the question is whether to make a
> transition now, and, if so, how.
>
> On balance, I think it's appropriate to make the change. ?I think
> there's an overall move towards ABIs without frame pointers, and that if
> x86 stakeholders want to change, it's not our place as GCC maintainers
> to do this. ?The fact that major distributions are already building the
> distribution itself (including its run-time libraries) without frame
> pointers suggests that users must be adapting. ?And the fact that ARM
> and MIPS users are still developing software suggests that people are
> learning how to deal with unwind tables. ?So, it's a significant
> transition, and there will be fallout, but it seems reasonable to me.
>
> Ultimately, however, I don't think this is an RM question. ?I think it
> should be determined by the x86 back-end maintainers. ?I'm happy to give
> my input, and to help moderate a discussion if appropriate, but this
> change does not affect any other architecture, so I think it's properly
> a question for the x86 back-end maintainers.
>

Thanks.


-- 
H.J.