From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 2129C3870917 for ; Fri, 15 Jan 2021 00:23:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2129C3870917 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 10F0MciP001513; Thu, 14 Jan 2021 18:22:38 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 10F0MbFO001511; Thu, 14 Jan 2021 18:22:37 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 14 Jan 2021 18:22:37 -0600 From: Segher Boessenkool To: "Kewen.Lin" Cc: GCC Patches , Bill Schmidt Subject: Re: [PATCH/RFC] combine: Tweak the condition of last_set invalidation Message-ID: <20210115002237.GX30983@gate.crashing.org> References: <6bcd32fa-d0ef-b136-ddd9-92a1d21f60af@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6bcd32fa-d0ef-b136-ddd9-92a1d21f60af@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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, 15 Jan 2021 00:23:40 -0000 Hi! On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote: > When I was investigating unsigned int vec_init issue on Power, > I happened to find there seems something we can enhance in how > combine pass invalidate last_set (set last_set_invalid nonzero). > > Currently we have the check: > > if (!insn > || (value && rsp->last_set_table_tick >= label_tick_ebb_start)) > rsp->last_set_invalid = 1; > > which means if we want to record some value for some reg and > this reg got refered before in a valid scope, we invalidate the > set of reg (last_set_invalid to 1). It avoids to find the wrong > set for one reg reference, such as the case like: > > ... op regX // this regX could find wrong last_set below > regX = ... // if we think this set is valid > ... op regX > > But because of retry's existence, the last_set_table_tick could It is not just because of retry: combine can change other insns than just i2 and i3, too. And even changing i2 requires this! The whole reg_stat stuff is an ugly hack that does not work well. For example, as in your example, some "known" value can be invalidated before the combination that wants to know that value is tried. We need to have this outside of combine, in a dataflow(-like) thing for example. This could take the place of REG_EQ* as well probably (which is good, there are various problems with that as well). > This proposal is to check whether the last_set_table safely happens > after the current set, make the set still valid if so. I don't think this is safe to do like this, unfortunately. There are more places that set last_set_invalid (well, one more), so at the very minimum this needs a lot more justification. Segher