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 1B8143850434 for ; Fri, 30 Oct 2020 09:21:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1B8143850434 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 B557B139F; Fri, 30 Oct 2020 02:21:11 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 251BB3F719; Fri, 30 Oct 2020 02:21:11 -0700 (PDT) From: Richard Sandiford To: Alan Modra via Gcc-patches Mail-Followup-To: Alan Modra via Gcc-patches , Alan Modra , Segher Boessenkool , richard.sandiford@arm.com Cc: Alan Modra , 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> Date: Fri, 30 Oct 2020 09:21:09 +0000 In-Reply-To: <20201002071105.GP15011@bubble.grove.modra.org> (Alan Modra via Gcc-patches's message of "Fri, 2 Oct 2020 16:41:05 +0930") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-6.7 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: Fri, 30 Oct 2020 09:21:13 -0000 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. Is there something PowerPC-specific that makes the relaxation safe for that target while not being safe on x86? 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). Thanks, Richard