From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26602 invoked by alias); 18 Dec 2019 15:29:34 -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 26590 invoked by uid 89); 18 Dec 2019 15:29:34 -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=IRA, bloat, H*f:sk:47b1043, REG_DEAD 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; Wed, 18 Dec 2019 15:29:32 +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 xBIFTR5J012985; Wed, 18 Dec 2019 09:29:28 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xBIFTRCX012984; Wed, 18 Dec 2019 09:29:27 -0600 Date: Wed, 18 Dec 2019 15:29:00 -0000 From: Segher Boessenkool To: Georg-Johann Lay , gcc@gcc.gnu.org, richard.sandiford@arm.com Subject: Re: Code bloat due to silly IRA cost model? Message-ID: <20191218152927.GY3152@gate.crashing.org> 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> 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-12/txt/msg00276.txt.bz2 Hi Richard, On Fri, Dec 13, 2019 at 10:31:54PM +0000, Richard Sandiford wrote: > >> 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. See below. > My point was the extra pseudo<-pseudo2 move is created by combine for > its own internal purposes And my point is that it is *not* internal purposes :-) This is done because we no longer combine with the hard register, but combining with just a register move is quite beneficial for many targets. We could (and probably should) do a 1->1 combine first, i.e. just simplification for every single insn, but that causes other problems right now. GCC 11, I hope. What happens is we have this: insn_cost 4 for 14: r44:SF=r22:SF REG_DEAD r22:SF insn_cost 4 for 2: r43:SF=r44:SF REG_DEAD r44:SF insn_cost 4 for 6: r22:SF=r43:SF REG_DEAD r43:SF insn_cost 0 for 7: r22:SF=call [`g'] argc:0 REG_CALL_DECL `g' (where insn 14 and r44 are created by make_more_copies). Now, insn 14 would normally be combined into insn 2. But this doesn't happen because the target prohibits it, with the targetm.class_likely_spilled_p in cant_combine_insn_p. I wonder if we still need that at all? Segher