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

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

On Thu, Aug 10, 2017 at 12:39 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Thu, Aug 10, 2017 at 9:09 AM, Richard Sandiford
> <richard.sandiford@linaro.org> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>> On Wed, Aug 9, 2017 at 10:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Wed, Aug 9, 2017 at 8:26 AM, Andi Kleen <andi@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.