llvm dev - Jan 2009 - [LLVMdev] PPC calling convention -- how to provide an environment pointer?

> Message: 8
> Date: Tue, 27 Jan 2009 18:00:26 -0500
> From: "Jonathan S. Shapiro" <shap at eros-os.com>
> Subject: Re: [LLVMdev] PPC calling convention -- how to provide	an
> 	environment	pointer?
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <1233097226.27873.11.camel at vmx>
> Content-Type: text/plain
>
> On Tue, 2009-01-27 at 08:59 -0800, Stuart Hastings wrote:
>> I assume you're talking about the 32-bit PowerPC.
>
> Also 64-bit, but the two register usage conventions are very close.
>
> Someone previously pointed out that R0 is usable as a scratch  
> register,
> and the CTR can be used. CTR *must* be used for the branch destination
> out of the ASM trampoline. R0 ends up getting used a lot for constant
> loads; we can (and in fact must) use it as a scratch register, but we
> cannot rely on it surviving past the prologue of the target function.
Hm.  I can't guarantee that GPR0 won't be used by any prologue, but I  
don't recall ever seeing such usage on Darwin.
>> AFAIK, the OS X dynamic linker does not "own" any registers. 
Here
>> are
>> some links to the Darwin ABI...
>
> In SVR4 ABI, R11 and R12 can be used. In Darwin, these are reserved  
> for
> uses associated with dynamic code generation and/or indirect call  
> using
> dynamic code generation, which is conceptually related.
>
> The part that is not clear to me is whether a call made by a C  
> function
> in Darwin is required to avoid R11 and R12 in order to allow for the
> possibility that dynamic code generation may happen. As long as this  
> is
> required, we can safely use R11 or R12 for our purposes. That would be
> great.
>
> I should perhaps explain that the use-case which is driving the asm
> design is a call from C code into a BitC procedure that requires a
> closure record pointer. The problem is:
>
>  1. The C code is oblivious about the need for this "extra"
argument,
>     and so cannot be expected to plan for it in register allocation.
>
>  2. We're trying to do a "generic" implementation at this
point for
>     reasons of simplicity, but even if we were willing to do an
>     implementation that uses knowledge of the full calling convention,
>     there are still cases in which none of the "official"
argument
>     registers is unused.
>
>  3. The design of most calling conventions doesn't consider the
>     requirements of modern language call compatibility, and
>     therefore doesn't reserve any register for this purpose.
>
> So it sounds like we can use R11 or R12 provided none of the function
> prologues also expect to use these. On SVR4 ABI this is true. Is it  
> also
> true for Darwin?
>
> If not, is there some other technique that we should consider? The
> obvious alternative would spill GPR3 into the parameter region, use
> that, and then reload after saving the ENV ptr, but I'm not clear
> whether the caller is obligated to have a parameter area in the case
> where *none* of its callees take any arguments.
>
> So: are R11 and R12 reserved enough on Darwin to be safe for our
> purposes?
>
Quoting from a table titled Register Preservation on page 22 of this  
PDF:

	http://developer.apple.com/documentation/developertools/Conceptual/LowLevelABI/Mac_OS_X_ABI_Function_Call_Guide.pdf

Reg		Preserved
Notes
---------------------------
GPR0	No
(No notes.)
...
GPR2	No
Available for general use.
...
GPR11	Yes in nested functions.  No in leaf functions.		
In nested functions, the caller passes its stackframe to the nested  
function in this register. In leaf functions, the register is  
available.  For details on nested functions, see the GCC  
documentation. This register is also used by lazy stubs in dynamic  
code generation to point to  the lazy pointer. functions.
...
GPR12	No
Set to the address of the branch target before an indirect call for  
dynamic code generation. This register is not set for a function that  
has been called directly; therefore, functions that may be called  
directly should not depend on this register being set up correctly.  
See Mach-O Programming Topics for more information.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

For PPC32, it seems like you may use GPR0 and GPR2 with impunity,  
GPR11 if your caller is not a nested function, and GPR12 if your  
callee is called directly (address never taken).  The PPC64 version of  
the Register Preservation table appears to be identical to the PPC32  
version, so any misteaks or misunderstandings in this email should be  
wrong there too.  :-)
> Thanks!
You're very welcome,

stuart