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 5E0EE385840E for ; Mon, 10 Jan 2022 13:06:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5E0EE385840E 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 70035 invoked from network); 10 Jan 2022 13:06:55 -0000 X-APM-Out-ID: 16418200157003 X-APM-Authkey: 257869/1(257869/1) 3 Received: from unknown (HELO ?192.168.1.214?) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 10 Jan 2022 13:06:55 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: Help with an ABI peculiarity From: Iain Sandoe In-Reply-To: Date: Mon, 10 Jan 2022 13:06:55 +0000 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Sandiford 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: Mon, 10 Jan 2022 13:06:59 -0000 > On 10 Jan 2022, at 10:46, Richard Sandiford = wrote: >=20 > Iain Sandoe writes: >> Hi Folks, >>=20 >> In the aarch64 Darwin ABI we have an unusual (OK, several unusual) = feature of the calling convention. >>=20 >> 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. >>=20 >> 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).. >>=20 >> 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). >>=20 >> I am trying to figure out where to implement this. >>=20 >> * the code that (in regular cases) decides on such promotions is = called _before_ we call target=E2=80=99s function_arg. >>=20 >> * 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). >>=20 >> 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. >>=20 >> 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. >=20 > 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.) 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 =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. >=20 > 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. >=20 > 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 =E2=80=9Cnot today, maybe there=E2=80=99s a simpler way=E2=80=9D).= thanks Iain