[llvm-commits] PR6059 patch

[Bob Wilson]

On Jan 22, 2010, at 4:45 PM, Rafael Espindola wrote:

>> I really think this needs to be handled in llvm_arm_should_pass_aggregate_in_mixed_regs().
> 
> The current use of a void type is the exact opposite of what we need
> for AAPCS. It is a case where the in memory representation contains
> unused bits that are not to be copied on function call. In this case
> the pad is to be *added*.

Oh, sorry.  I guess I misunderstood what that was for.

> My current plan is to do this in a similar way to gcc:
> *) From my last patch copy the "HandlePad" bits
> *) Add a LLVM_TRY_PASS_AGGREGATE_CUSTOM. It will take "type",
> "ScalarElts" and "C". If it returns true, the argument has been
> handled nothing else has to be done. If it returns false we continue
> trying.
> 
> The nice thing about this is
> *) LLVM_TRY_PASS_AGGREGATE_CUSTOM will be the one calling methods on
> "C" and have a lot more flexibility than just returning a boolean or
> elements in an array.
> *) The code will be protected by a check that the calling convention is AAPCS

It seems like we already have too many different hooks for passing aggregates, and I'm not convinced this is necessary.

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.