"H.J. Lu" <hjl.to...@gmail.com> writes: > On Wed, Aug 9, 2017 at 10:28 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Wed, Aug 9, 2017 at 8:26 AM, Andi Kleen <a...@firstfloor.org> 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. Thanks, Richard