This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] i386: Don't use frame pointer without stack access

"H.J. Lu" <> writes:
> On Wed, Aug 9, 2017 at 10:28 AM, H.J. Lu <> wrote:
>> On Wed, Aug 9, 2017 at 8:26 AM, Andi Kleen <> wrote:
>>>> This must be much more specific.  How does it impact:
>>>> 1. LTO
>>>> 2. Function inlining.
>>>> 3. Partial function inlining.
>>>> 4. Shrink-wrapping.
>>>> Any of them can impact function stack frame.
>>> It doesn't. It's just to get back to the previous state.
>>> Also these others already have explicit options to disable them.
>> How about
>> item -fkeep-frame-pointer
>> @opindex fkeep-frame-pointer
>> Keep the frame pointer in a register for functions.  This option always
>> forces a new stack frame for all functions regardless of whether
>> @option{-fomit-frame-pointer} is enabled or not.  Disabled by default.
> Here is the updated patch with -fkeep-frame-pointer.

It sounds like there's still some disagreement about what this option
should mean; Andi's and Arjan's replies didn't seem to be asking for
the same thing.

I think as implemented the patch just retains the GCC 7 x86 behaviour of
-fno-omit-frame-pointer, i.e. forces a frame to be created *somewhere*
between the start and end addresses of the function, but makes no
guarantee where.  It could be a bundle of three instructions somewhere
in the middle of a basic block, and the code might not be executed for
all paths through the function (e.g. it might only be executed on
error paths).

I think even if we think that's useful, it should be documented clearly.
Otherwise people might assume that a function f is guaranteed to set up
a frame every time it's called.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]