From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id C7D903894C30 for ; Mon, 10 Jan 2022 10:46:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C7D903894C30 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4E8D5ED1; Mon, 10 Jan 2022 02:46:43 -0800 (PST) Received: from localhost (unknown [10.32.98.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CC5173F5A1; Mon, 10 Jan 2022 02:46:42 -0800 (PST) From: Richard Sandiford To: Iain Sandoe Mail-Followup-To: Iain Sandoe , GCC Development , richard.sandiford@arm.com Cc: GCC Development Subject: Re: Help with an ABI peculiarity References: Date: Mon, 10 Jan 2022 10:46:41 +0000 In-Reply-To: (Iain Sandoe's message of "Fri, 7 Jan 2022 21:06:28 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Mon, 10 Jan 2022 10:46:45 -0000 Iain Sandoe writes: > Hi Folks, > > In the aarch64 Darwin ABI we have an unusual (OK, several unusual) featur= e of the calling convention. > > When an argument is passed *in a register* and it is integral and less th= an SI it is promoted (with appropriate signedness) to SI. This applies whe= n the function parm is named only. > > When the same argument would be placed on the stack (i.e. we ran out of r= egisters) - it occupies its natural size, and is naturally aligned (so, for= instance, 3 QI values could be passed as 3 registers - promoted to SI .. o= r packed into three adjacent bytes on the stack).. > > The key is that we need to know that the argument will be placed in a reg= ister before we decide whether to promote it. > (similarly, the promotion is not done in the callee for the in-register c= ase). > > 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 t= ype). > > I=E2=80=99ve experimented with various schemes - specifically that tm.fu= nction_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 ca= llback. > > 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. 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 =E2=80=9Cgarbage=E2=80=9D rtl.) An alternative might be to make promote_function_arg a =E2=80=9Cproper=E2= =80=9D 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