On Thu, Aug 10, 2017 at 12:39 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > 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. >
I will check in my previous patch today. Thanks. -- H.J.