[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-25 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

--- Comment #9 from Thomas Koenig  ---
(In reply to Richard Earnshaw from comment #8)
> (In reply to Thomas Koenig from comment #7)
> > Would it make sense to document this somewhere?  Or did I just miss it? :-)
> 
> Possibly, but I've no idea where.  It's too target-specific to put under the
> generic documentation for -fomit-frame-pointer and I don't think there's a
> section in the manual that really documents the target-specific behaviours
> of generic options.

Hm, maybe a chapter "Architecture-specific implementation choices"
to document those cases where the ABI gives some leeway could be a
place to put it.  It could have sections on architecture.

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-24 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

--- Comment #8 from Richard Earnshaw  ---
(In reply to Thomas Koenig from comment #7)
> Would it make sense to document this somewhere?  Or did I just miss it? :-)

Possibly, but I've no idea where.  It's too target-specific to put under the
generic documentation for -fomit-frame-pointer and I don't think there's a
section in the manual that really documents the target-specific behaviours of
generic options.

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-23 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

--- Comment #7 from Thomas Koenig  ---
(In reply to Richard Earnshaw from comment #5)
> This was a deliberate design choice.  Although the frame chain is not set up
> by code that omits the frame pointer, the chain of frames that are set up by
> other functions is still valid this way.  This ensures that any code that
> does try to walk the frame chain will not crash.  If we reused the frame
> pointer for other purposes, then any code trying to walk the frame chain (eg
> backtrace()) would encounter an invalid record and likely crash.


Would it make sense to document this somewhere?  Or did I just miss it? :-)

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-23 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

--- Comment #6 from Richard Earnshaw  ---
For completeness.

The AArch64 ABI lists 4 alternatives with respect to having a frame chain. When
-fomit-frame-pointer is used, GCC implements this one:

- It may require the frame pointer to address a valid frame record at all
times, except that any subroutine may elect not to create a frame record

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-23 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Richard Earnshaw  ---
This was a deliberate design choice.  Although the frame chain is not set up by
code that omits the frame pointer, the chain of frames that are set up by other
functions is still valid this way.  This ensures that any code that does try to
walk the frame chain will not crash.  If we reused the frame pointer for other
purposes, then any code trying to walk the frame chain (eg backtrace()) would
encounter an invalid record and likely crash.

With 31 main registers, the benefit from one additional one is not especially
large.

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-22 Thread gccbug at provalid dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

gccbug at provalid dot com changed:

   What|Removed |Added

 CC||gccbug at provalid dot com

--- Comment #4 from gccbug at provalid dot com ---
I think the ABI might have softened on this point at
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#general-purpose-registers.
 It says the platform can let x29 be used as a general-purpose callee-saved
register in section 6.4.6.

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-22 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

--- Comment #3 from Thomas Koenig  ---
(In reply to Andrew Pinski from comment #2)
> See https://gcc.gnu.org/pipermail/gcc-patches/2016-September/456662.html
> 
> I think this is by design of the ABI ...

The workaround mentioned in the thread does not appear to work,
 -O3 -fomit-frame-pointer -fcall-used-x29 yields
cc1: error: cannot use 'x29' as a call-used register

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

--- Comment #2 from Andrew Pinski  ---
See https://gcc.gnu.org/pipermail/gcc-patches/2016-September/456662.html

I think this is by design of the ABI ...

[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified

2023-08-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096

--- Comment #1 from Andrew Pinski  ---
#define FIXED_REGISTERS \
  { \
0, 0, 0, 0,   0, 0, 0, 0,   /* R0 - R7 */   \
0, 0, 0, 0,   0, 0, 0, 0,   /* R8 - R15 */  \
0, 0, 0, 0,   0, 0, 0, 0,   /* R16 - R23 */ \
0, 0, 0, 0,   0, 1, 0, 1,   /* R24 - R30, SP */ \


It is specifically marked as a fixed register ...