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

[Bob Wilson]

On Dec 11, 2009, at 10:33 AM, Rafael Espindola wrote:

>> byval arguments are always copied to memory, so they do have addresses, but they may be passed in registers.  Look at PPCISelLowering's LowerFormalArguments_Darwin, for example.
> 
> For ARM this part should not be on memory, that is not the layout
> mandated by the ABI.

Right, so codegen has to recognize that and copy the arguments to/from the registers mandated by the ABI.

> 
>> For pr5406, we use byval on all the other major supported architectures except ARM.  We should fix ARM first to use the approach that we know works.  After that, if you want to initiate a project to find a more elegant solution, that would be fantastic.  It is pretty horrible that we essentially require all targets to implement byval to get compatibility with any sane ABI.
> 
> No we don't. Take x86-64 for example. Since char[5] <= 16 bytes
> llvm-gcc decomposes the structure:
> 
> declare void @f(i32, i32, i32, i64)
> 
> If  I change 5 with 17 I get
> 
> declare void @f(i32, i32, i32, %struct.foo* byval)
> 
> 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.

> 
>>> 
>>> For example, in x86-64 something like
>>> 
>>> %struct.s = type { i64 }
>>> define i64 @f(%struct.s* byval %a)
>>> 
>>> gets passed on the stack. It would be passed in registers on arm with
>>> your proposal.
>>> 
>>> I also want to fix this bug first and try to improve things afterward.
>>> The first option (using a final i8) looks the easiest to implement
>>> right now. Would it be OK with you if I finish implementing that
>>> first?
>> 
>> I don't think that's the right way to go.
> 
> What about the second proposal:
> 
> %struct.foo_part = type { i8 }
> declare arm_aapcscc void @f(i32, i32, i32, i32, %struct.foo_part* byval)
> 
> Sorry, I am not going to implement byval splitting in the ARM backend
> to just immediately open a bug report about it producing bad quality
> code. We know what will and will not be in the stack early on.

You are right about the code quality.  If you want to implement something like the x86-64 solution, that would be great.