> The change as voted simply does not work at a technical level because
> -mno-omit-leaf-frame-pointer is an architecture-specific GCC option that
> is not available on all Fedora architectures. I don't think
> -fno-omit-frame-pointer is well-exercised on s390x, so I wouldn't want
> to use it
> On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
>
> I don't think the two are comparable at all, neither in terms of
> potential performance impact (register pressure across an entire
> program vs at specific API call points in some unique cases) nor in
> terms of the be
> Andrii,
>
> copilot to pilot, you are responding to Jakub Jelinek's points, not
Copilot? Pilot? I don't understand this euphemism. And yes, I'm well aware who
I'm replying to, thank you.
> Neal's. Jakub is a compiler/toolchain engineer with considerable
And not sure why you are implying
> On Tue, Dec 06, 2022 at 05:46:11PM -0000, Andrii Nakryiko wrote:
>
> Depends on how large functions are. If you have lots of small functions,
> it can be more than 50% of instructions you get the frame pointer wrong.
You might be technically correct, but if some application is
> On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
>
> My full comment in that blog post is:
>
> "We need a proper study of performance and code size to understand the
> magnitude of the impact created by _FORTIFY_SOURCE=3 additional
> runtime code generation. However the performance and code
> On Tue, Dec 06, 2022 at 03:12:19AM +, Gary Buhrmaster wrote:
>
> Note that is not a fully equivalent scenario. The no-omit-frame-pointer
> proposal was only offering a functional debugging benefit to a fairly
> small number of users who are also developers, while adding a likely
>
> On Tue, Dec 06, 2022 at 08:13:51AM -0500, Neal Gompa wrote:
>
> That is nonsense. Even with -fno-omit-frame-pointers, you can't rely
> on frame pointers, they are not accurate in function prologues and epilogues
> and they are total garbage e.g. in a lot of functions written in assembly.
