[Bug target/100811] New: Consider not omitting frame pointers by default on targets with many registers

[Bug target/100811] New: Consider not omitting frame pointers by default on targets with many registers

[grasland at lal dot in2p3.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

            Bug ID: 100811
           Summary: Consider not omitting frame pointers by default on
                    targets with many registers
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: grasland at lal dot in2p3.fr
  Target Milestone: ---

Since at least GCC 4 (Bugzilla's duplicate search points me to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13822), GCC has been omitting
frame pointers by defaults when optimizations are enabled, unless the extra
-fno-omit-frame-pointer flag is specified.

As far as I know, the rationale for doing this was that :

- On architectures with very few general purpose registers like 32-bit x86,
strictly following frame pointer retention discipline has a prohibitive
performance cost.
- Debuggers do not need frame pointers to do their job, as they can leverage
DWARF or PDB debug information instead.

While these arguments are valid, I would like to make the case that frame
pointers may be worth keeping by default on hardware architectures where this
is not too expensive (like x86_64), for the purpose of making software
performance analysis easier.

Unlike debuggers, sampling profilers like perf cannot afford the luxury of
walking the process stack using DWARF any time a sample is taken, as that would
take too much time and bias the measured performance profile. Instead, when
using DWARF for stack unwinding purposes, they have to take stack samples and
post-process them after the fact. Furthermore, since copying the full program
stack on every sample would generate an unbearable volume of data, they usually
can only afford to copy the top of the stack (upper 64KB at maximum for perf),
which will lead to corrupted stack traces when application stacks get deep or
there are lots of / large stack-allocated objects.

For all these reasons, DWARF-based stack unwinding is a somewhat unreliable
technique in profiling, where it's really hard to get >90% of your profile's
stack traces to be correctly reconstructed all the way to _start or _clone. The
remaining misreconstructed stack traces will translate into profile bias
(underestimated "children" overhead measurements), and thus performance
analysis mistakes.

To make matters worse, DWARF-based unwinding is relatively complex, and not
every useful runtime performance analysis tool supports it. For example,
BPF-based tracing tools, which are nowadays becoming popular due to their
highly appealing ability to instrument every kernel or user function on the
fly, do not currently support DWARF-based stack unwinding, most likely because
feeding the DWARF debug info into the kernel-based BPF program would either be
prohibitively expensive, a security hole, or a source of recursive tracing
incidents (tracing tool generates syscalls of the kind that it is tracing,
creating an infinite loop).

Therefore, I think -fno-omit-frame-pointer should be the default on
architectures where the price to pay is not too high (like x86_64), which
should ensure that modern performance analysis tooling works on all popular
Linux distributions without rebuilding the entire world. In this scheme,
-fomit-frame-pointer would remain as a default option for targets where it is
really needed (like legacy 32-bit x86), and as a specialist option for those
cases where the extra ~1% of performance is really truly needed and worth its
cost.

What do you think?

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is a very bad idea, slowing down everything for the rare case that
something needs to be profiled.  And profilers can afford to unwind too if
needed.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer <fw at gcc dot gnu.org> ---
I expect that profilers will soon be able to use the shadow stack on x86, which
will be more efficient and reliable than traversing frame pointers.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also on say PowerPC, not omitting the frame pointer gives no benifit whats so
ever really with respect to backtracing.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[hiraditya at msn dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

AK <hiraditya at msn dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hiraditya at msn dot com

--- Comment #4 from AK <hiraditya at msn dot com> ---
On AArch64 (typically mobile platforms) app developers typically would enable
frame pointers by default because it helps with crash reporting.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to AK from comment #4)
> On AArch64 (typically mobile platforms) app developers typically would
> enable frame pointers by default because it helps with crash reporting.

s/AArch64 (typically mobile platforms)/phone\tablet/ 
Because aarch64 is also used for servers and network applicances too.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think aarch64 defaults to -fno-omit-frame-pointer anyway.
    /* Disable fomit-frame-pointer by default.  */
    { OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

--- Comment #7 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> I think aarch64 defaults to -fno-omit-frame-pointer anyway.
>     /* Disable fomit-frame-pointer by default.  */
>     { OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },

It's required by some (all?) AArch64 ABIs, certainly on GNU/Linux.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[hiraditya at msn dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

--- Comment #8 from AK <hiraditya at msn dot com> ---
Should we enable frame-pointers by default for RISCV64 as well?

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Why?
It should be enabled by default only if it is effectively mandated by the ABI
and/or doesn't affect performance at all (and is actually useful in functions
that don't need it like functions with alloca/VLAs; see the PowerPC case).

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #10 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Frankly I've seen too much "slowing down everyone's system just for some
debugging/profiling/whatever tools" thing.  So I'd say a clear "no".

You may argue 1% performance degradation is acceptable, but the change would be
a bad start to justify other changes and at last we'll accumulate a 9.5%
degradation with 10 such changes one day.

If DWARF unwinding does not work properly, try to fix it or revise the DWARF
specification, instead of making every system slower.

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
DWARF unwinding works properly, just in Linux kernel they decided they don't
want it in the kernel (I think they had some non-perfect implementation in the
past and it got removed).