[llvm-commits] [llvm-gcc-4.2] r86892 - /llvm-gcc-4.2/trunk/gcc/llvm-abi.h
bob.wilson at apple.com
Fri Dec 11 15:31:06 CST 2009
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.
More information about the llvm-commits