From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id 9D54D3857C74 for ; Fri, 7 Jan 2022 21:06:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D54D3857C74 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sandoe.co.uk Received: (qmail 76827 invoked from network); 7 Jan 2022 21:06:29 -0000 X-APM-Out-ID: 16415895887682 X-APM-Authkey: 257869/1(257869/1) 5 Received: from unknown (HELO ?192.168.1.214?) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 7 Jan 2022 21:06:29 -0000 From: Iain Sandoe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Help with an ABI peculiarity Message-Id: Date: Fri, 7 Jan 2022 21:06:28 +0000 To: GCC Development X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2022 21:06:32 -0000 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=E2=80=99s function_arg. * OVERRIDE_ABI_FORMAT seems to be called too early (we don=E2=80=99t = have enough information on the function - to decide to set the PARM = passed-as type). I=E2=80=99ve 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=E2=80=99m = interested. thanks Iain