https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172
Wilco <wilco at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilco at gcc dot gnu.org
--- Comment #1 from Wilco <wilco at gcc dot gnu.org> ---
Firstly it's important to be clear this is about adding support for a frame
chain for unwinding.
A frame pointer is something different since it is used for addressing local
variables. Historically Arm compilers only supported a frame pointer, not a
frame chain for unwinding. So different Arm backends use different frame
pointer registers and there is no defined layout since it is not designed for
unwinding.
Why does this matter? Well as your examples show, if you want to emit a frame
chain using standard push/pop, it typically ends up pointing to the top of the
frame. That is the worst possible position for a frame pointer on Thumb - while
Arm supports negative immediate offsets up to 4KB, Thumb-1 doesn't support
negative offsets at all, and Thumb-2 supports offsets up to -255 but only with
32-bit instructions. So the result of conflating the frame chain and frame
pointer implies a terrible codesize hit for Thumb.
There is also an issue with using r7 as the frame chain in that you're now
reserving a precious low register callee-save and just use it once in a typical
function. So using r7 is a very bad idea for Thumb.
Your examples suggest LLVM suffers from both of these issues, and IIRC it still
uses r11 on Arm but r7 on Thumb. That is way too inefficient/incorrect to
consider a defacto standard.
