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 C9D7338582BA for ; Fri, 8 Jul 2022 20:24:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9D7338582BA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=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 268KNfSp030633; Fri, 8 Jul 2022 15:23:41 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 268KNeE2030632; Fri, 8 Jul 2022 15:23:40 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 8 Jul 2022 15:23:40 -0500 From: Segher Boessenkool To: Roger Sayle Cc: "'Kewen.Lin'" , gcc-patches@gcc.gnu.org, "'David Edelsohn'" Subject: Re: [PATCH/RFC] combine_completed global variable. Message-ID: <20220708202340.GB25951@gate.crashing.org> References: <001a01d89239$713109e0$53931da0$@nextmovesoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01d89239$713109e0$53931da0$@nextmovesoftware.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 08 Jul 2022 20:24:43 -0000 Hi! On Thu, Jul 07, 2022 at 08:40:38PM +0100, Roger Sayle wrote: > Although I've not been able to reproduce your ICE (using gcc135 > on the compile farm), I completely agree with Segher's analysis > that the Achilles heel with my approach/patch is that there's > currently no way for the backend/recog to know that we're in a > pass after combine. To know combine has been run at least once already, yes. It currently won't run more than one of course, but the only thing that really stops running it more than once was historically that combine was one of the more expensive passes. Now otoh it is really quite cheap. Currently combine is one of the last passes before RA. It likely will be nice to run combine quite early as well (or a limited version of it that is), just like other optimisation passes already are, including its closest relative fwprop. > Rather than give up on this optimization (and a similar one for > I386.md where test;sete can be replaced by xor $1 when combine > knows that nonzero_bits is 1, but loses that information afterwards), > I thought I'd post this "strawman" proposal to add a combine_completed > global variable, matching the reload_completed and regstack_completed > global variables already used (to track progress) by the middle-end. It should be called differently, given the above. > I was wondering if I could ask you could test the attached patch > in combination with my previous rs6000.md patch (with the obvious > change of reload_completed to combine_completed) to confirm > that it fixes the problems you were seeing. > > Segher/Richard, would this sort of patch be considered acceptable? > Or is there a better approach/solution? There is the thing I have been working on for about a year now, that makes combine's nonzero_bits superfluous, by making the generic version more capable than combine's version. That is a better way forward imo, it solves many other problems as well. But it isn't ready yet. Your patch is fine with a name change (and documentation change) indicating it means that combine has run at least once. Thanks! Segher