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

[Rafael Espindola]

> 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.

> 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.

>>
>> 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.

Cheers,
-- 
Rafael Ávila de Espíndola