From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id BE1FF3858D3C; Fri, 11 Mar 2022 17:29:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE1FF3858D3C Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id A049D65C20; Fri, 11 Mar 2022 12:29:38 -0500 (EST) Message-ID: Subject: Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820] From: Xi Ruoyao To: Qing Zhao Cc: Richard Sandiford , YunQiang Su , "gcc-patches@gcc.gnu.org" , Jakub Jelinek , Jeff Law Date: Sat, 12 Mar 2022 01:29:36 +0800 In-Reply-To: References: <93ab62b2b9473733e5118f4265b61804978adfd7.camel@mengyan1223.wang> <53408AB1-0FA4-4529-95D9-A10FA8999DF6@oracle.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3030.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 11 Mar 2022 17:29:44 -0000 On Fri, 2022-03-11 at 16:08 +0000, Qing Zhao wrote: > Why there is “mthi $0” instruction, but there is NO emit_move_insn(HI, CONST_0)? > Is such mismatch a bug? If not, why? > > >  In theory it's possible > > to emit the mthi instruction explicitly here though, but we'll need to > > clear something NOT in need_zeroed_hardregs for MIPS anyway (see below). > > One question here,  is there situation when only HI is cleared but LO is not cleared? No, if I interpret the document of -fzero_call_used_regs and attribute((zero_call_used_regs(...))) correctly. A 2-reg multiplication (or division) always set the value of both HI and LO. Richard has added a comment for this in mips.cc: > 12868 /* After a multiplication or division, clobbering HI makes > 1 the value of LO unpredictable, and vice versa. This means > 2 that, for all interesting cases, HI and LO are effectively > 3 a single register. > 4 > 5 We model this by requiring that any value that uses HI > 6 also uses LO. */ This is also why the handling of emit_move_insn(HI, CONST_0) was removed, I guess (the removal happened in the same commit adding this comment). > > > > Okay, I see.  So, each ST_REGi register is a 1-bit pseudo register? > But physically each of them is 1-bit in a physical register? Yes. > > > > Because there is no elegant way to clear one specific FCC bit in MIPS. > > A "ctc1 $0, $25" instruction will zero them altogether.  If we really > > need to clear only one of them (let's say ST_REG3), we'll have to emit > > something like > > > > mtc1  $0, $0           # zero FPR0 to ensure it won't contain sNaN > > c.f.s $3, $0, $0 > > > > Then we'll still need to clobber FPR0 with zero.  So anyway we'll have > > to clear some registers not specified in need_zeroed_hardregs. > > So, “c.f.s” instruction can be used to clear ONLY one specific FCC bit? > But you have to clear one FPR (floating pointer register?) first to avoid raising exception? > My question here is:  is there a case when only FCC need to be cleared but no FPR need to be cleared? Yes, for example: double a, b; struct x { double a, b; }; struct x f(void) { struct x x = { .a = a, .b = b }; if (a < b) x.a = x.b; return x; } It does not need to zero the two FPRs, as they contain the return value. But a FCC bit needs to be cleared. > If NOT, then we can always pick one FPRi  before c.f.s to avoid the > issue you mentioned (We’ll have to clear some registers not specified > in need_zeroed_hardregs). I'm now thinking: is there always at least one *GPR* which need to be cleared? If it's true, let's say GPR $12, and fcc0 & fcc2 needs to be cleared, we can use something like: cfc1 $12, $25 andi $25, 5 ctc1 $12, $25 move $12, $0 > > And the question is: is it really allowed to return something other than > > a subset of need_zeroed_hardregs for a TARGET_ZERO_CALL_USED_REGS hook? > > Although currently there is no assertion added to force this > requirement, I still think that we should keep it. > > The “need_zeroed_hardregs” is computed based on > > 1. User’s request from command line option; > 2. Data flow info of the routine; > 3. Abi info of the target; > > If zero_call_used_regs target hook return registers out of > “need_zeroed_hardregs” set, then it might out of the user’s exception, > it should be considered as a bug, I think. I have the same concern. But now I'm too sleepy... Will try to improve this tomorrow. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University