From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74239 invoked by alias); 22 Nov 2019 16:39:18 -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 74231 invoked by uid 89); 22 Nov 2019 16:39:18 -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=H*f:sk:mptsgmh, H*i:sk:mptsgmh, H*MI:sk:mptsgmh 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; Fri, 22 Nov 2019 16:39:17 +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 xAMGdCZx018653; Fri, 22 Nov 2019 10:39:12 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xAMGdBpQ018652; Fri, 22 Nov 2019 10:39:11 -0600 Date: Fri, 22 Nov 2019 16:39:00 -0000 From: Segher Boessenkool To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: Re: Add a new combine pass Message-ID: <20191122163911.GE9491@gate.crashing.org> References: <20191118235659.GO16031@gate.crashing.org> <20191119203932.GC16031@gate.crashing.org> <20191120204556.GP16031@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/msg02208.txt.bz2 On Thu, Nov 21, 2019 at 08:32:14PM +0000, Richard Sandiford wrote: > Segher Boessenkool writes: > > It's not great if every pass invents its own version of some common > > infrastructure thing because that common one is not suitable. > > > > I.e., can this be fixed somehow? Maybe just by having a restricted DU > > chains df problem? > > Well, it'd probably make sense to make fwprop.c's approach available > as a "proper" df interface at some point. Hopefully if anyone wants the > same thing as fwprop.c, they'd do that rather than copy the code. :-) > >> * Updating a full, ordered def-use chain after a move is a linear-time > >> operation, so whatever happens, we'd need to apply some kind of limit > >> on the number of uses we maintain, with something like that integer > >> point range for the rest. Yeah. > >> * Once we've analysed the insn and built its def-use chains, we don't > >> look at the df_refs again until we update the chains after a successful > >> combination. So it should be more efficient to maintain a small array > >> of insn_info_rec pointers alongside the numerical range, rather than > >> walk and pollute chains of df_refs and then link back the insn uids > >> to the pass-local info. > > > > So you need something like combine's LOG_LINKS? Not that handling those > > is not quadratic in the worst case, but in practice it works well. And > > it *could* be made linear. > > Not sure why what I've used isn't what I need though :-) 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. > >> 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? > So there's only one case in which it isn't a win, but the number of > tests is tiny. So I agree there's no justification for trying this in > combine proper as things stand (and I wasn't arguing otherwise FWIW). > I'd still like to keep it in the new pass because it does help > *sometimes* and there's no sign yet that it has a noticeable > compile-time cost. So when does it help? I can only think of cases where there are problems elsewhere. > It might also be interesting to see how much difference it makes for > run-combine=4 (e.g. to see how much it makes up for the current 2-insn > limit)... Numbers are good :-) Segher