[llvm-commits] [llvm-gcc-4.2] r86892 - /llvm-gcc-4.2/trunk/gcc/llvm-abi.h

[Bob Wilson]

On Dec 10, 2009, at 5:08 PM, Rafael Espindola wrote:

>> I think it's a bad idea to try to do this in target-independent code.
>>  Whether the information goes in the high part or the low part of the
>> register is target-dependent (there's some correlation with endianness), and
>> just which structs need special treatment is also target-dependent.  I think
>> there's even a target where
>>  struct { char[3] a;}
>> and
>>  struct { short a; char b; }
>> are passed differently.
>> 
>> I think most existing targets use byval, so I'd use that; there's lots of
>> prior art to copy.
> 
> 
> I think I failed to pass by point: How would you expand
> 
> --------------------------
> struct foo {
> char c[5];
> };
> 
> void f(int a, int b, int c, struct foo d) {
> ...
> }
> -----------------------

I don't think I get your point.  The expansion of that may be target-specific.  E.G., x86 passes "d" using "byval", but x86-64 expands it to an i64.

> 
> Byval was created to force something to the stack
> (http://llvm.org/bugs/show_bug.cgi?id=1521). In this case the first 4
> bytes have to go in a register. The last byte goes to the stack. I can
> use byval, but only for the last byte. I still need to know when the
> registers are over so that I can split the structure at that point.

Byval does not force things to the stack.  From the llvm IR perspective, byval arguments look like they are passed in memory, but the codegen needs to understand the target ABI and figure out how to pass them.  The values (or portions of values) that are actually passed in registers are then copied into memory.  There are some performance problems with this, and it's certainly not pretty, but we should fix the ARM ABI issues before trying to redesign the way llvm handles argument passing.