From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17307 invoked by alias); 6 Feb 2020 02:49:45 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 17296 invoked by uid 89); 6 Feb 2020 02:49:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=touched X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2020 02:49:40 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0162nNeC090122; Wed, 5 Feb 2020 21:49:39 -0500 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xyhn4xxsy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Feb 2020 21:49:38 -0500 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 0162m93W001319; Thu, 6 Feb 2020 02:49:38 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma03dal.us.ibm.com with ESMTP id 2xykc9m3vy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 02:49:38 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0162nbKQ51577288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Feb 2020 02:49:37 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40BDF28058; Thu, 6 Feb 2020 02:49:37 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E5C952805A; Thu, 6 Feb 2020 02:49:36 +0000 (GMT) Received: from genoa.aus.stglabs.ibm.com (unknown [9.40.192.157]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTPS; Thu, 6 Feb 2020 02:49:36 +0000 (GMT) From: Jiufu Guo To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, wschmidt@linux.ibm.com Subject: Re: [PATCH, rs6000]: mark clobber for registers changed by untpyed_call References: <1580910807-24635-1-git-send-email-guojiufu@linux.ibm.com> <20200205192514.GU22482@gate.crashing.org> Date: Thu, 06 Feb 2020 02:49:00 -0000 In-Reply-To: <20200205192514.GU22482@gate.crashing.org> (Segher Boessenkool's message of "Wed, 5 Feb 2020 13:25:14 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00314.txt.bz2 Segher Boessenkool writes: > On Wed, Feb 05, 2020 at 09:53:27PM +0800, Jiufu Guo wrote: >> As PR93047 said, __builtin_apply/__builtin_return does not work well with >> -frename-registers. This is caused by return register(e.g. r3) is used to >> rename another register, before return register is stored to stack. >> >> This patch fix this issue by emitting clobber for those egisters which >> maybe changed by untyped call. > > Yeah. untyped_call does > > /* The optimizer does not know that the call sets the function value > registers we stored in the result block. We avoid problems by > claiming that all hard registers are used and clobbered at this > point. */ > emit_insn (gen_blockage ()); > > but blockage does not say registers are used and clobbered: > > @cindex @code{blockage} instruction pattern > @item @samp{blockage} > This pattern defines a pseudo insn that prevents the instruction > scheduler and other passes from moving instructions and using register > equivalences across the boundary defined by the blockage insn. > This needs to be an UNSPEC_VOLATILE pattern or a volatile ASM. > > Many archs have this same implementation of untyped_call (and of > blockage, too). It all just works by luck (or it doesn't work). > > What we have is: > > emit_call_insn (gen_call (operands[0], const0_rtx, const0_rtx)); > > for (i = 0; i < XVECLEN (operands[2], 0); i++) > { > rtx set = XVECEXP (operands[2], 0, i); > emit_move_insn (SET_DEST (set), SET_SRC (set)); > } > > ... and nothing in the rtl stream says that those return registers are > actually set by that call. Maybe we should use gen_call_value? Can we > ever be asked to return more than a single thing here? I was also thinking about using "gen_call_value" or "emit_clobber (r3)" which could generate rtl: "%3:DI=call [foo]" or "call [foo]; clobber r3". This could tell optimizer that %3 is changed. While there are potential issues that untyped_call may change other registers. So, mark clobber for all touched registers maybe more safe. > > Some trivial patch comments: > >> gcc/ >> 2020-02-05 Jiufu Guo >> >> PR target/93047 >> * config/rs6000/rs6000.md (untyped_call): add emit_clobber. > > "Add", capital. Thanks, > >> gcc/testsuite >> 2020-02-05 Jiufu Guo >> >> PR target/93047 >> * gcc.dg/torture/stackalign/builtin-return-2.c: New case. > > "New test case." (And there is trailing whitespace here; Git warns > about that, so this won't happen much in the future :-) ) Oh, get it, thanks. The withspace is after this line. Jiufu > > > Segher