From patchwork Sat Dec 14 20:14:34 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 301293 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 83F2E2C0085 for ; Sun, 15 Dec 2013 12:41:30 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=GlPS2IftoLk9DSwsB HcNTIqh284BOzAExHn8LhcugCPQg22hg51+/0NVzHWyPFDm1fgAqzgjjFiIm6FFw n3ZyV2iWGK4DfakETqYNvU5V5dJP1H3My48Im6eia9mW3Dq6xCIT8SXyy8Uq7C7W 73S8i91MeSuXHqBNYapds6RHSc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=lh4IFjCHrKdc2mA1OsiNKZg EqmM=; b=gNJHZFgn0FNC5E2P3PsI334nVYNT3g/NYln105dS+H5cuoZyunb+Sh3 /eEVcQJ/nLVnVKeL6+h6kSphKPWUVs/I6Fr3oh6yRYXYl9Tg/PU0a2rznYI8y0rl vqMCtlKKQhexjeX8pXCS8Nk0hATpDxCCuhp00G9sVRCcdUHLj2aw= Received: (qmail 31279 invoked by alias); 14 Dec 2013 20:14:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 31269 invoked by uid 89); 14 Dec 2013 20:14:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Dec 2013 20:14:44 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Vrvbj-0001gi-BP from Tom_deVries@mentor.com ; Sat, 14 Dec 2013 12:14:39 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Dec 2013 12:14:39 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Sat, 14 Dec 2013 20:14:36 +0000 Message-ID: <52ACBC2A.6070806@mentor.com> Date: Sat, 14 Dec 2013 21:14:34 +0100 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jeff Law CC: jan Hubicka , GCC Patches Subject: Re: question about REG_PARM_STACK_SPACE usage in expand_call References: <52AA2145.6000109@mentor.com> <52AA9E6F.6040400@redhat.com> In-Reply-To: <52AA9E6F.6040400@redhat.com> On 13-12-13 06:43, Jeff Law wrote: >> Was this meant perhaps? >> ... >> || (reg_parm_stack_space != REG_PARM_STACK_SPACE >> (current_function_decl)) > I think you're probably right. > > sibcall/tailcall basically re-use the current function's stack Jeff, Right, say we have function a tail-calling function b. If the sibcall optimization is done, function a deallocates it's stack frame before calling function b. > so if there's a > difference between REG_PARM_STACK_SPACE (fndecl) and REG_PARM_STACK_SPACE > (current_function_decl), then we can't perform a sibcall/tailcall optimization. > > So the pattern that we want to check a property of fndecl and > current_function_decl and if they don't match, then don't do a sibcall is > repeated in a few places. > I wonder if OUTGOING_REG_PARM_STACK_SPACE makes a difference here. If OUTGOING_REG_PARM_STACK_SPACE == 0, it is the responsibility of the callee to allocate the area reserved for arguments passed in registers. AFAIU, both functions a and b would do that in their own stack frame, and there's no need to test for reg_parm_stack_space != REG_PARM_STACK_SPACE (current_function_decl). If OUTGOING_REG_PARM_STACK_SPACE != 0, it is the responsibility of the caller to allocate the area reserved for arguments passed in registers. Which means that function a and b share the space allocated by the caller of function a. AFAIU, what is required is reg_parm_stack_space <= REG_PARM_STACK_SPACE (current_function_decl). So this might be a more precise fix: ... ... But probably not a stage3 fix. > Assuming you bootstrap & test successfully, consider a patch which fixes this > pre-approved. > Bootstrapped and reg-tested attached patch on x86_64. Committed to trunk. Thanks, - Tom > jeff 2013-12-14 Tom de Vries * calls.c (expand_call): Fix REG_PARM_STACK_SPACE comparison. diff --git a/gcc/calls.c b/gcc/calls.c index 2226e78..501474b 100644 --- a/gcc/calls.c +++ b/gcc/calls.c @@ -2595,7 +2595,7 @@ expand_call (tree exp, rtx target, int ignore) /* If outgoing reg parm stack space changes, we can not do sibcall. */ || (OUTGOING_REG_PARM_STACK_SPACE (funtype) != OUTGOING_REG_PARM_STACK_SPACE (TREE_TYPE (current_function_decl))) - || (reg_parm_stack_space != REG_PARM_STACK_SPACE (fndecl)) + || (reg_parm_stack_space != REG_PARM_STACK_SPACE (current_function_decl)) #endif /* Check whether the target is able to optimize the call into a sibcall. */