[llvm-commits] PR6059 patch

[Bob Wilson]

On Jan 22, 2010, at 5:17 PM, Rafael Espindola wrote:

>> It seems like we already have too many different hooks for passing aggregates, and I'm not convinced this is necessary.
> 
> And I think the reason for that is that none of them is generic
> enough. Just passing the ABIClient should be sufficient to implement
> anything that the backend needs. A good cleanup would be to remove the
> other hooks.

Well, that's another thing altogether!  If the purpose of your change is to somehow clean up the argument passing in llvm-gcc, then I'm all in favor.  I don't really know how to do that myself, and I don't think I understand the details of what you're proposing.  I do think it would be a bad idea to add a new hook just for ARM AAPCS.

> 
>> Actually, now that I think about it, you should be able to pass the struct from pr6059 as a pair of i64 values, and the backend should be responsible for inserting the padding.  If it doesn't then there is a separate bug in the backend.
> 
> I really don't think so. We know in the FE what the alignment will be
> and that the argument will be split. Doing this exposes the individual
> 32 bit units to the IL and reduces the requirements on the backend.

The backend had better be able to correctly handle a function like:

x(i32 arg0, i64 arg1, i64 arg2)

The first argument goes in r0; r1 is unused; arg1 goes in register r2 and r3; and arg2 goes on the stack (with 64-bit alignment).  That is exactly what you're looking for in pr6059, right?

This is the general approach of llvm-gcc: translate the arguments to something that will make the backend do the right thing.  I don't understand why that doesn't work in this case.  Am I missing something?