From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81971 invoked by alias); 26 Nov 2019 01:42:54 -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 81960 invoked by uid 89); 26 Nov 2019 01:42:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=realistic, stopping, H*i:sk:mptk17n, H*f:sk:mptk17n X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Nov 2019 01:42:53 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id xAQ1gmQX015003; Mon, 25 Nov 2019 19:42:48 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xAQ1glZ2015002; Mon, 25 Nov 2019 19:42:47 -0600 Date: Tue, 26 Nov 2019 01:44:00 -0000 From: Segher Boessenkool To: gcc-patches@gcc.gnu.org, Nicholas Krause , richard.sandiford@arm.com Subject: Re: Add a new combine pass Message-ID: <20191126014247.GC9491@gate.crashing.org> References: <20191118235659.GO16031@gate.crashing.org> <20191119203932.GC16031@gate.crashing.org> <20191120204556.GP16031@gate.crashing.org> <20191122163911.GE9491@gate.crashing.org> <20191125221350.GW9491@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg02374.txt.bz2 On Mon, Nov 25, 2019 at 11:08:47PM +0000, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Mon, Nov 25, 2019 at 09:16:52PM +0000, Richard Sandiford wrote: > >> Segher Boessenkool writes: > >> > I am wondering the other way around :-) Is what you do for combine2 > >> > something that would be more generally applicable/useful? That's what > >> > I'm trying to find out :-) > >> > > >> > What combine does could use some improvement, if you want to hear a > >> > more direct motivations. LOG_LINKS just skip references we cannot > >> > handle (and some more), so we always have to do modified_between etc., > >> > which hurts. > >> > >> The trade-offs behind the choice of representation are very specific > >> to the pass. > > > > Yes, but hopefully not so specific that every pass needs a completely > > different representation ;-) > > Well, it depends. Most passes make do with df (without DU/UD-chains). > But since DU/UD-chains are naturally quadratic in the general case, > and are expensive to keep up to date, each DU/UD pass is going to have > make some compromises. It doesn't seem too bad that passes make > different compromises based on what they're trying to do. (combine: > single use per definition; fwprop.c: track all uses, but for dominating > definitions only; sched: fudged via a param; regrename: single > definition/multiple use chains optimised for renmaing; combine2: full > live range information, but limited use list; etc.) combine actually *calculates* DU chains almost completely, it just throws away most of that information (it wants to have LOG_LINKS, as it did ages ago). The only thing stopping us from doing that right now is that not all uses are counted (some are skipped). Since combine works only within BBs, DU chains are linear to compute, and UD chains are trivial (and just linear to compute). Updating is quadratic in general, sure. Luckily in most realistic cases it is cheap (most, sigh) (insns aren't combined to very far away). > So yeah, if passes want to make roughly the same compromises, it would > obviously be good if they shared a representation. But since each pass > does something different, I don't think it's a bad sign that they make > different compromises and use different representations. > > So I don't think a new pass with a new representation is in itself a > sign of failure. Oh, I don't think so either. I just wonder if it would be useful more generically :-) > >> >> >> Target Tests Delta Best Worst Median > >> >> >> avr-elf 1341 -111401 -13824 680 -10 > >> >> > > >> >> > Things like this are kind of suspicious :-) > >> >> > >> >> Yeah. This mostly seems to come from mopping up the extra moves created > >> >> by make_more_copies. So we have combinations like: > >> >> > >> >> 58: r70:SF=r94:SF > >> >> REG_DEAD r94:SF > >> >> 60: r22:SF=r70:SF > >> >> REG_DEAD r70:SF > >> > > >> > Why didn't combine do this? A target problem? > >> > >> Seems to be because combine rejects hard-reg destinations whose classes > >> are likely spilled (cant_combine_insn_p). > > > > Ah, okay. And that is required to prevent ICEs, in combine2 as well > > then -- ICEs in RA. > > Not in this case though. The final instruction is a hardreg<-pseudo move > whatever happens. There's nothing special about r70 compared to r94. So the target hook could be improved? Or, this doesn't matter anyway, the extra register move does not prevent any combinations, and RA should get rid of it when that is beneficial. But you see smaller code in the end, hrm. Segher