On Thu, Aug 10, 2017 at 9:09 AM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > "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.
As said earlier, I think we should proceed with the previous patch (that documents -fno-omit-frame-pointer limitations), It was demonstrated that the patch does not make current situation worse. -fkeep-frame-pointer is an orthogonal issue, and this option should guarantee frame formation in *all* situations.This means that the option should disable (partial) inlining, shrink-wrapping, etc. Actually, it would disable so much optimizations, that its usefullnes is questioned. OTOH, nobody ever complained about limited FP debugging "experience" when mentioned optimizations were activated. BTW: The option should be called -fforce-frame-pointer, but I really doubt about its usefullnes. Uros.