Bug 98018 - Option to force frame pointer
Summary: Option to force frame pointer
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 10.2.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-26 15:40 UTC by Jan Smets
Modified: 2023-08-22 17:31 UTC (History)
4 users (show)

See Also:
Host:
Target: x86_64-*-* i?86-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Smets 2020-11-26 15:40:46 UTC
As discussed in PR 97902 we'd need an option that disables all optimizations that may affect the generation of a frame pointer.
Comment 1 H.J. Lu 2020-11-26 15:49:17 UTC
Something like, -fneed-frame-pointer, -fforce-frame-pointer or -fgenerate-frame-pointer.
Comment 2 Uroš Bizjak 2020-11-26 16:07:53 UTC
I vote for -fforce-frame-pointer.
Comment 3 H.J. Lu 2020-11-26 16:23:47 UTC
-fforce-frame-pointer should disable

1. Tail call.
2. Inlining.  Should inlining be totally disabled? Which inlining should be
disabled? What do do with static inline and extern inline?
3. Frame pointer optimization.
4. Anything else?
Comment 4 Richard Biener 2020-11-27 07:32:53 UTC
Note always_inline inlining cannot be disabled.  Should it disable function splitting and IPA transforms that require thunks?  Thus any transform that
might add or remove a frame?  Even if the thunk might use a tailcall?
Comment 5 Martin Liška 2020-11-27 11:16:00 UTC
About the IPA passes, it's likely quite close to -flive-patching=inline-only-static what we want here.
Comment 6 Richard Sandiford 2020-12-03 12:21:14 UTC
I assume this isn't just about forcing a function to set up
a frame pointer: I assume we also need the function to set up
the frame pointer at the earliest opportunity and keep it valid
for as long as possible.  This means (at least) that:

* We need to disable shrink-wrapping of the frame pointer
* There needs to be a full scheduling barrier after the
  frame pointer has been set up and before it is torn down

So I don't think this is just about disabling optimisations
(unless perhaps we disable scheduling completely).  It seems
like an entirely new mode that will involve new code.