RE: Use of r31 on the powerpc/booke:mpc85xx architecture

["Scislowicz, Adam" <Adam.Scislowicz%amd.com@localhost>]

After reading the various ABI guides it seems like the original workaround to 
appease -fno-omit-frame-pointer may have unintended side effects. If GCC is no 
longer aware of r31 being tampered with it cannot be guaranteed to preserve r31 
in the GP Regs section of the stack via the generated prologue and epilogue. 
Would it not be better to for now state that -fno-omit-frame-pointer is 
violating the ABI used in practice and should be avoided on the powerpc 
platform? In my search for understanding I found people coming to a similar 
conslusion in their use of gcc to compile the Linux kernel for the powerpc 
architecture.

Warm Regards,
Adam

________________________________________
From: port-powerpc-owner%NetBSD.org@localhost 
[port-powerpc-owner%NetBSD.org@localhost] on behalf of Dennis Ferguson 
[dennis.c.ferguson%gmail.com@localhost]
Sent: Monday, September 10, 2012 11:48 AM
To: Scislowicz, Adam
Cc: Matt Thomas; port-powerpc%NetBSD.org@localhost
Subject: Re: Use of r31 on the powerpc/booke:mpc85xx architecture

On 10 Sep, 2012, at 12:11 , Scislowicz, Adam wrote:
> Yes, I was still using -fno-omit-frame-pointer when I experienced the issue, 
> perhaps it is responsible. I will try to reproduce shortly with different 
> build flags. Thank you for the response, I need to read the PPC ABI as I 
> haven't yet which is why I was unsure of the register allocations and 
> googling got me the incorrect answer the first time. Also I am not yet 
> familiar with good practices regarding gcc flags for the P2020 or more 
> generally powerpc. Most of my time has been spent on x86 and ARM thus far.
>
> Understood wrt stmw/lwm, was misreading the inline assembly wrt counting 
> colons and PPC ASM wasn't fresh in my mind, context switch in progress ;)

Note, though, that it isn't perfectly clear what the PPC ABI is.

The original PPC ELF ABI supplement, e.g. here

    http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf

allowed r31 to optionally be dedicated to holding "environmental
pointers", whatever that is.  I suspect the option you are using
makes gcc dedicate r31 to this, probably to make alloca() a bit
cheaper (likely at the expense of making everything which doesn't
use alloca() a bit more expensive).

This option was unique to that ABI spec.  The (older) PowerOpen ABI,
used by AIX, specified r31 as a normal, callee-saved register, as
did the PowerPC "Embedded ABI" here:

    http://www.freescale.com/files/32bit/doc/app_note/PPCEABI.pdf

More recently there has been work to unify the "desktop" and
"embedded" ABIs into one, e.g. here

    
https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf

and that work also removes the option of using r31 as anything
other than a normal, non-volatile register.  And, finally, the
(related) 64 bit ELF ABI, here

    http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html

has never special-cased r31 either.

So while the original PPC ELF ABI provided the option of using r31 for
a dedicated function this was probably a bad idea (as you've discovered
the PowerPC instruction set has several useful instructions which
are hardwired to use r31, so dedicating r31 to some function gets in the
way of using those instructions) and the option has been removed in newer
work.  If -fno-omit-frame-pointer is making gcc special-case r31 then
you probably shouldn't use that flag.  It causes gcc to generate code
that doesn't conform to the most recent version of the PPC ABI and
makes it harder to use certain features of the PPC instruction set.

Dennis Ferguson