This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] i386: Don't use frame pointer without stack access
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, Andi Kleen <andi at firstfloor dot org>, Arjan van de Ven <arjan at linux dot intel dot com>, Michael Matz <matz at suse dot de>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Alexander Monakov <amonakov at ispras dot ru>, Uros Bizjak <ubizjak at gmail dot com>, richard dot sandiford at linaro dot org
- Date: Thu, 10 Aug 2017 09:39:08 +0200
- Subject: Re: [PATCH] i386: Don't use frame pointer without stack access
- Authentication-results: sourceware.org; auth=none
- References: <87wp6e7ykz.fsf@linaro.org> <87shh27yho.fsf@linaro.org> <87d18589em.fsf@linaro.org> <D780188F-2074-4B0B-AAAF-D882932ACC47@gmail.com> <CAMe9rOrh8zdFZtCRw3GfEkApY1hqJ70OSugvSRnqUWxrk+8hsA@mail.gmail.com> <alpine.LSU.2.21.1708091356230.15613@wotan.suse.de> <CAMe9rOqYfswAq_3h=vADptn1v6NcpyvALLCxBLOMDJKdZR97=w@mail.gmail.com> <874ltg4wb2.fsf@firstfloor.org> <a1e17209-90a5-8f94-6eff-9d058d171cc9@linux.intel.com> <CAMe9rOofwWjCrdXhdtePbfwCyENxi6igPMJdeDGwqRhrUXN9LQ@mail.gmail.com> <20170809152622.GJ3044@two.firstfloor.org> <CAMe9rOob+P-BD1Ob17R78OX977R-OjS+Tj1pUq9dYmBLV8jDuw@mail.gmail.com> <CAMe9rOqqLu+SP-36X=G9N3CoEysjE0G4s=u68FKzpJgARy_V0A@mail.gmail.com> <877eybx5jx.fsf@linaro.org>
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.
-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.