[LLVMdev] [PowerPC] ABI questions

Jonas Maebe jonas.maebe at elis.ugent.be
Fri Aug 1 07:51:23 PDT 2014


On 01 Aug 2014, at 16:39, Iain Sandoe wrote:

> On 1 Aug 2014, at 14:19, Jonas Maebe wrote:
>
>> There's one small difference between the two: with the 64 bit ELFv1/ 
>> SVR4 ABI, tail padding for structs passed by value is only  
>> performed in case the struct is larger than 8 bytes, while for AIX  
>> 64 bit it's always done. As an aside, on Darwin/ppc64 it's done if  
>> the aggregate's size is not in [1,2,4].
>
> JFTR,
> 1/ The darwin ppc64 case is, indeed,  relatively sane (but darwin  
> ppc64 is not yet implemented in clang or llvm).

Well, its requirement to pass individual floating point and vector  
fields of structs as if they were passed as separate parameters while  
packing everything else still together into integer registers is  
another matter...

> 2/ The Darwin ppc32 struct layout case is more complex (also  
> inherited from AIX).
>
> See "Mac OS X ABI Function Call Guide" (Feb 2009) [Apple]
> - 32-bit PowerPC Calling Conventions
>   - Data Types and Alignments (Power case, which is the default).

I know, I've implemented the parameter passing for ppc32 for Linux,  
Mac OS X and AIX in our own compiler :) (and I'm currently working on  
cleaning up the 64 bit ppc parameter passing while adding support for  
ELFv2). In general, I consider the Darwin/ppc32 ABI much easier than  
the Darwin/ppc64 ABI.

> I have almost completed an implementation of this ABI and hope to  
> post patches in the next few weeks (test cases to make and polishing  
> needed).
>
> As of now, effectively, clang has "no detailed idea" of the Darwin  
> PPC32 or PPC64 ABIs (except in so much as they are 32/64 bit  
> RISCish) it is really quite amazing that any code works at all.

Absolutely! I guess the main reason is that very few system APIs make  
use of call-by-value struct parameters. For "project-internal" code,  
it doesn't really matter what you use as long as it's the same  
everywhere.


Jonas



More information about the llvm-dev mailing list