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 A468638708E4 for ; Mon, 2 Nov 2020 14:27:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A468638708E4 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 5B94F30E; Mon, 2 Nov 2020 06:27:44 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BDF693F66E; Mon, 2 Nov 2020 06:27:43 -0800 (PST) From: Richard Sandiford To: Alan Modra Mail-Followup-To: Alan Modra , gcc-patches@gcc.gnu.org, Segher Boessenkool , richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, Segher Boessenkool Subject: Re: [PATCH] calls.c:can_implement_as_sibling_call_p REG_PARM_STACK_SPACE check References: <20201002071105.GP15011@bubble.grove.modra.org> <20201030134035.GF15956@bubble.grove.modra.org> Date: Mon, 02 Nov 2020 14:27:42 +0000 In-Reply-To: <20201030134035.GF15956@bubble.grove.modra.org> (Alan Modra's message of "Sat, 31 Oct 2020 00:10:35 +1030") 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.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Mon, 02 Nov 2020 14:27:46 -0000 Alan Modra writes: > On Fri, Oct 30, 2020 at 09:21:09AM +0000, Richard Sandiford wrote: >> Alan Modra via Gcc-patches writes: >> > This moves an #ifdef block of code from calls.c to >> > targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000, >> > define REG_PARM_STACK_SPACE or OUTGOING_REG_PARM_STACK_SPACE macros >> > that might vary depending on the called function. Macros like >> > UNITS_PER_WORD don't change over a function boundary, nor does the >> > MIPS ABI, nor does TARGET_64BIT on PA-RISC. Other targets are even >> > more trivially seen to not need the calls.c code. >> > >> > Besides cleaning up a small piece of #ifdef code, the motivation for >> > this patch is to allow tail calls on PowerPC for functions that >> > require less reg_parm_stack_space than their caller. The original >> > code in calls.c only permitted tail calls when exactly equal. >>=20 >> Is there something PowerPC-specific that makes the relaxation safe >> for that target while not being safe on x86? > > It is quite possible that x86 can relax this condition too, I'm just > not familiar enough with all the x86 ABIs know with any certainty. By > moving the test to the target hook we allow target maintainers to have > full say in the matter. > >> I take your point about x86 and PowerPC being the only two affected >> targets. But the interface does still take an fndecl on all targets, >> so I think the target-independent assumption should be that the value >> might vary depending on function. So I guess an alternative would be >> to relax the target-independent condition and make the x86 hook enforce >> the stricter condition (if it really is needed). > > Yes, except that actually the REG_PARM_STACK_SPACE condition for > PowerPC can be removed entirely. I agree that doing as you suggest > would be OK for PowerPC, it would just mean we continue to do some > unnecessary work in the non-trivial rs6000_function_parms_need_stack. Ah, OK. If you did the check in rs6000_function_parms_need_stack, what would the final version of the condition look like, including the future changes you have planned? My main point here is that I think it would be good to have target-independent code check the lowest common denominator that we know GCC can support on targets with nonzero REG_PARM_STACK_SPACEs, rather than force all those targets to repeat the check. (Admittedly =E2=80=9Call=E2=80=9D is just =E2=80=9Ctwo=E2=80=9D as things stand, but st= ill=E2=80=A6) Targets like i386 can conservatively continue to enforce the old condition but target-independent code would follow the new and more relaxed rs6000 rules. Thanks, Richard