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 07CF0385BF9B for ; Thu, 2 Dec 2021 21:24:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 07CF0385BF9B 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 56411 invoked from network); 2 Dec 2021 21:24:33 -0000 X-APM-Out-ID: 16384802735640 X-APM-Authkey: 257869/1(257869/1) 6 Received: from unknown (HELO ?192.168.1.214?) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 2 Dec 2021 21:24:33 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [PATCH 1/2] Add cumulative_args_t variants of TARGET_FUNCTION_ROUND_BOUNDARY and friends From: Iain Sandoe In-Reply-To: Date: Thu, 2 Dec 2021 21:24:32 +0000 Cc: Richard Biener , Maxim Blinov , GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211113094202.96232-1-maxim.blinov@embecosm.com> To: Jeff Law X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-8.9 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 21:24:36 -0000 > On 2 Dec 2021, at 21:08, Jeff Law via Gcc-patches = wrote: > On 11/22/2021 8:15 AM, Richard Biener via Gcc-patches wrote: >> On Mon, Nov 22, 2021 at 3:40 PM Maxim Blinov = wrote: >>> Hi Richard, >>>=20 >>> The purpose of this patch is to give more of the target code access = to >>> the cumulative_args_t structure in order to enable certain = (otherwise >>> currently impossible) stack layout constraints, specifically for >>> parameters that are passed over the stack. For example, there are = some >>> targets (not yet in GCC trunk) which explicitly require the >>> distinction between named and variadic parameters in order to = enforce >>> different alignment rules (when passing over the stack.) Such a >>> constraint would be accommodated by this patch. >>>=20 >>> The patch itself is very straightforward and simply adds the = parameter >>> to the two functions which we'd like to extend. The motivation of >>> defining new target hooks was to minimize the patch size. >> I would prefer to adjust the existing hooks if there's currently no = way to >> implement the aarch64 darwin ABI instead of optimizing for patch = size. > Agreed. Additionally I don't think we want any -f options controlling = this behavior. Perhaps the choice of expression was not ideal - we were trying to = minimize the invasiveness of the change (my steer to Maxim, so mea culpa there). The concern was that re-using existing hooks would touch every target, = including all those we have no way to test. I wonder if C++ will allow us to have a default NULL argument to the = hook so that it=E2=80=99s a NOP change unless a target chooses to populate = that arg. (I guess an overload will not work since we are populating a fn pointer = table). >> I have no opinion on whether passing down cummulative args is the >> proper thing to do design-wise. It might be that = TARGET_FUNCTION_ARG_BOUNDARY >> is only one part that cummulative args using code should look at >> (given you don't show the other users of function_arg_boundary that = do not >> conveniently have a CA struct around). > In the past I think we passed some additional parameters indicated = where the last named parameter was so that it could be used to set up = the CA struct. But if the aarch64 darwin ABI needs that info somewhere = we didn't before, then we'd likely need to add the CA structure. yeah, the problem is in knowing that we need to switch from natural = alignment of parms (so that parm N+1 is only padded sufficiently to be naturally = aligned) to word boundary. We=E2=80=99ll figure out a revised patch as soon as time permits. Iain >=20 >=20 > Jeff