> On 10 Jan 2022, at 10:46, Richard Sandiford <richard.sandif...@arm.com> wrote:
>
> Iain Sandoe <i...@sandoe.co.uk> writes:
>> Hi Folks,
>>
>> In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature
>> of the calling convention.
>>
>> When an argument is passed *in a register* and it is integral and less than
>> SI it is promoted (with appropriate signedness) to SI. This applies when
>> the function parm is named only.
>>
>> When the same argument would be placed on the stack (i.e. we ran out of
>> registers) - it occupies its natural size, and is naturally aligned (so, for
>> instance, 3 QI values could be passed as 3 registers - promoted to SI .. or
>> packed into three adjacent bytes on the stack)..
>>
>> The key is that we need to know that the argument will be placed in a
>> register before we decide whether to promote it.
>> (similarly, the promotion is not done in the callee for the in-register
>> case).
>>
>> I am trying to figure out where to implement this.
>>
>> * the code that (in regular cases) decides on such promotions is called
>> _before_ we call target’s function_arg.
>>
>> * OVERRIDE_ABI_FORMAT seems to be called too early (we don’t have enough
>> information on the function - to decide to set the PARM passed-as type).
>>
>> I’ve experimented with various schemes - specifically that tm.function_arg
>> can alter the mode of the register in the appropriate cases, and then
>> calls.c can act on the case that the mode has been changed by that callback.
>>
>> It seems probable that this approach can be made non-invasive - but...
>> ... if someone can point me at a better solution - I’m interested.
>
> I agree there doesn't seem to be an out-of-the-box way of doing this.
> I'm not sure about having two different ways of specifying promotion
> though. (For one thing, it should be possible to query promotion
> without generating “garbage” rtl.)
In this case, it does not appear to be possible to do that without the
cumulative args info .. so your next point is the logical design.
> An alternative might be to make promote_function_arg a “proper”
> ABI hook, taking a cumulative_args_t and a function_arg_info.
> Perhaps the return case should become a separate hook at the
> same time.
>
> That would probably require more extensive changes than just
> updating the call sites, and I haven't really checked how much
> work it would be, but hopefully it wouldn't be too bad.
>
> The new hook would still be called before function_arg, but that
> should no longer be a problem, since the new hook arguments would
> give the target the information it needs to decide whether the
> argument is passed in registers.
Yeah, this was my next port of call (I have looked at it ~10 times and then
decided “not today, maybe there’s a simpler way”).
thanks
Iain
