public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Iain Sandoe <iain@sandoe.co.uk>
To: GCC Development <gcc@gcc.gnu.org>
Subject: Help with an ABI peculiarity
Date: Fri, 7 Jan 2022 21:06:28 +0000	[thread overview]
Message-ID: <CD187C76-0620-457C-A0B7-B4ADBB6014FB@sandoe.co.uk> (raw)

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.

thanks
Iain


             reply	other threads:[~2022-01-07 21:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07 21:06 Iain Sandoe [this message]
2022-01-07 21:55 ` Paul Koning
2022-01-08 16:35   ` Jeff Law
2022-01-10  8:38     ` Florian Weimer
2022-01-10 13:27       ` Iain Sandoe
2022-01-10 13:46         ` Florian Weimer
2022-01-11 12:53         ` Eric Gallager
2022-01-11 11:57       ` Richard Earnshaw
2022-01-10 10:46 ` Richard Sandiford
2022-01-10 13:06   ` Iain Sandoe
2022-01-20 22:32     ` Richard Sandiford
2022-01-21 11:19       ` Iain Sandoe
2022-01-21 12:22         ` Richard Sandiford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CD187C76-0620-457C-A0B7-B4ADBB6014FB@sandoe.co.uk \
    --to=iain@sandoe.co.uk \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).