From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23577 invoked by alias); 13 Dec 2019 22:31:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23562 invoked by uid 89); 13 Dec 2019 22:31:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Dec 2019 22:31:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EF43E30E; Fri, 13 Dec 2019 14:31:55 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5FDB03F6CF; Fri, 13 Dec 2019 14:31:55 -0800 (PST) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,Georg-Johann Lay , gcc@gcc.gnu.org, richard.sandiford@arm.com Cc: Georg-Johann Lay , gcc@gcc.gnu.org Subject: Re: Code bloat due to silly IRA cost model? References: <47b10439-21b8-81f6-3838-a2bcd0fa8048@gjlay.de> <5DEFFCD4.4080903@gcc.gnu.org> <84093aae-3567-65a1-581a-17ef599b09ad@gcc.gnu.org> <20191213160445.GT3152@gate.crashing.org> <20191213185946.GV3152@gate.crashing.org> Date: Fri, 13 Dec 2019 22:31:00 -0000 In-Reply-To: <20191213185946.GV3152@gate.crashing.org> (Segher Boessenkool's message of "Fri, 13 Dec 2019 12:59:46 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00200.txt.bz2 Segher Boessenkool writes: > On Fri, Dec 13, 2019 at 04:22:11PM +0000, Richard Sandiford wrote: >> Segher Boessenkool writes: >> > On Fri, Dec 13, 2019 at 12:45:47PM +0000, Richard Sandiford wrote: >> >> combine's to blame for the fact that we have two pseudo registers rather >> >> than one. See the comments about the avr-elf results in: >> >> >> >> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02150.html >> >> >> >> for more details. >> > >> > It's not combine's fault if register allocation does a bad job. And we >> > should *not* generate worse code in combine just because it exposes a >> > problem in RA (with 2-2 and make_more_copies we generate better code on >> > average, on all targets I tested, 50 or so). >> > >> > If having two pseudos here is not an advantage, then RA should optimise >> > one away. It does usually, why not here? >> >> I didn't say it was combine's fault that RA was bad. I said it was >> combine's fault that we have two pseudos rather than one. > > But that is not a fault, that is on purpose. > > Before this change, combine would forward hard registers into pseudos > greedily. RA can do a better job than that. I don't think anyone's disputing that. You quoted the initial text above out of context. Johann had asked why the RA even needed to do anything for the posted testcase, where we have the equivalent of "foo (bar ())", bar returns a value in register X and foo takes an argument in register X. I was trying to explain that we still need: (set pseudo X) ... (set X pseudo) in order to avoid spill failures in all but trivial cases, and that we rely on the RA to make a good allocation choice for the pseudo. So I think what you said above is basically explaining back to me what I'd said in the context that was snipped. But we only need one temporary pseudo register to avoid the spill failures, whereas in Johann's case the RA sees two: (set pseudo2 X) (set pseudo pseudo2) ... (set X pseudo2) My point was the extra pseudo<-pseudo2 move is created by combine for its own internal purposes and pseudo2 isn't something *the RA* needs to avoid spill failures. But in this case combine fails to fold the extra move with anything and so the move "leaks out" to later passes, including RA. The snipped context linked to the message where we'd discussed this, including why combine fails to restore the original X<-pseudo<-X chain for avr-elf. It also shows that avr-elf code improved significantly if we *did* restore that original chain (which the new combine pass happened to do, although that just fell out in the wash rather than being a specific aim). In a perfect world, we could keep adding more and more pseudos to a move chain without affecting the output of the RA. But it's not too surprising if that isn't always true in practice. After all, the point of adding pseudo2 in the first place is that *combine* handles pseudo<-pseudo2<-X differently from just pseudo<-X. ;-) Thanks, Richard > If you found a case where > RA does not do a good job, let's fix that? > > (And combine does get rid of two pseudos, if that is a good idea to do. > If instructions do not properly combine, it can not, of course). > > > Segher