From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.sandiford@arm.com>
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by sourceware.org (Postfix) with ESMTP id 29880385840D
 for <gcc@gcc.gnu.org>; Thu, 20 Jan 2022 22:32:09 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29880385840D
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 B76BC101E;
 Thu, 20 Jan 2022 14:32:08 -0800 (PST)
Received: from localhost (unknown [10.32.98.88])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 204133F73D;
 Thu, 20 Jan 2022 14:32:08 -0800 (PST)
From: Richard Sandiford <richard.sandiford@arm.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Mail-Followup-To: Iain Sandoe <iain@sandoe.co.uk>,
 GCC Development <gcc@gcc.gnu.org>, Maxim Blinov <maxim.blinov@embecosm.com>,
 richard.sandiford@arm.com
Cc: GCC Development <gcc@gcc.gnu.org>, Maxim Blinov <maxim.blinov@embecosm.com>
Subject: Re: Help with an ABI peculiarity
References: <CD187C76-0620-457C-A0B7-B4ADBB6014FB@sandoe.co.uk>
 <mptzgo3x3zi.fsf@arm.com>
 <EBC7E620-0C78-406C-8827-F7F265B03D43@sandoe.co.uk>
Date: Thu, 20 Jan 2022 22:32:06 +0000
In-Reply-To: <EBC7E620-0C78-406C-8827-F7F265B03D43@sandoe.co.uk> (Iain
 Sandoe's message of "Mon, 10 Jan 2022 13:06:55 +0000")
Message-ID: <mpt4k5yox7d.fsf@arm.com>
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.4 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 <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jan 2022 22:32:10 -0000

Iain Sandoe <iain@sandoe.co.uk> writes:
>> On 10 Jan 2022, at 10:46, Richard Sandiford <richard.sandiford@arm.com> =
wrot>> An alternative might be to make promote_function_arg a =E2=80=9Cprop=
er=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 th=
en
> decided =E2=80=9Cnot today, maybe there=E2=80=99s a simpler way=E2=80=9D).

BTW, finally catching up on old email, I see this is essentially also
the approach that Maxim was taking with the TARGET_FUNCTION_ARG_BOUNDARY
patches.  What's the situation with those?  Sorry for not responding
to them earlier.

Thanks,
Richard