From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by sourceware.org (Postfix) with ESMTPS id 69D433857804 for ; Fri, 30 Oct 2020 13:40:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 69D433857804 Received: by mail-pf1-x442.google.com with SMTP id o129so5321808pfb.1 for ; Fri, 30 Oct 2020 06:40:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=B6N3oNabjvkd+Oe771LR8deHCy/0rBDjtNfbo7xlWEo=; b=JTzgMKyU/mAShYShBA8S8iePiKY4uL9Svjt1w9Fy0h6+Okjl9KSuvMN5qoi2krohJI joKuH+aj38AcwPObFu8a5b+PrtczqswKLO11Pmjt3/vw3tnpin9MUx88bRspYrFqG+5X LnN2lZ45HgPNC7HtwCqzoOC2N2rGnwoIr5Rt450a8/DHuPMrT0jdp1CcyImRf/oEnDxe 4rbEUP3Bfo3ERS0A08eaX9mawk+thPWdp69t+MTS2lpIWvUzZOtPNsqVyQyG8LqO/OAj LmFV5Y17tFExKPogHCzsQ8LqLWqtckCaw/I0jpCHcC+C7N+uPQGSJe8+SLustlPGqhpF w4KQ== X-Gm-Message-State: AOAM530DXg/0N3M6PnACitIzVEysL2hjd/SWolosKPVM+HEai5v9lzXk 6EiAZB3tc0aJSd+RzYy6hJo= X-Google-Smtp-Source: ABdhPJya+vFGkMkPqcXoldMVHiaQU5qKAvFMBhrALqLr60oiOBoh/2zSvIG2gX+j8hfROHVDgskeSA== X-Received: by 2002:a63:4546:: with SMTP id u6mr2260419pgk.311.1604065241516; Fri, 30 Oct 2020 06:40:41 -0700 (PDT) Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id c140sm6051809pfb.124.2020.10.30.06.40.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2020 06:40:40 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 1A5EA858B7; Sat, 31 Oct 2020 00:10:36 +1030 (ACDT) Date: Sat, 31 Oct 2020 00:10:35 +1030 From: Alan Modra To: 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 Message-ID: <20201030134035.GF15956@bubble.grove.modra.org> References: <20201002071105.GP15011@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 13:40:43 -0000 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. > > 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. Would it be better if I post the patches again, restructuring them as 1) completely no functional change just moving the existing condition to the powerpc and i386 target hooks, and 2) twiddling the powerpc target hook? Thanks for your time spent reviewing, and comments! -- Alan Modra Australia Development Lab, IBM