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

[Bob Wilson]

On Dec 11, 2009, at 12:28 PM, Rafael Espindola wrote:

>>> Which is good, since *all* of stuct foo is passed on the stack.
>> 
>> You're right about x86-64 -- I was misremembering that.  x86 and ppc use byval.
> 
> So, for x86 that is fine too since all of the struct will be passed in
> the stack. I don't know ppc,
> 
>> You are right about the code quality.  If you want to implement something like the x86-64 solution, that would be great.
> 
> Yes, I want something like x86-64. The big difference that we have to
> account for on ARM is that it can split structures with a part going
> to registers and a part going to the stack.
> 
> *) For the part that goes in registers, we should just use i32 (x86-64
> uses i64). Do you agree with that?
> *) For the part that goes in the stack I see 2 options
> 1) Use simple integers (i8, i16 ...)
> 2) Use a byval
> 
> Option 1 is easier to implement. Option 2 is probably the best since
> it makes it explicit that something is going to memory. One
> disadvantage of option 2 is that we introduce a new  type representing
> the bits that go to memory.
> 
> Do you see other options? Which one do you like best?

I don't know.

Honestly, I think those choices may be the least of your worries.  If llvm-gcc is going to figure out exactly how each argument will be passed, there are a lot of details to get right.  If you can come up with something that works with APCS, AAPCS, and AAPCS-hardfloat, preferably both big- and little-endian (watch out for structure padding differences with those), and passes the GCC ABI compatibility testsuite, I don't much care how you do it.

If I don't get pulled into other work, I'll probably go ahead with the "byval" implementation.  That would at least give you a baseline to compare against.