Re: Help with an ABI peculiarity

[Richard Sandiford <richard.sandiford@arm.com>]

Iain Sandoe <iain@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.)

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.

Thanks,
Richard