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 10D34389851F for ; Sat, 25 Apr 2020 12:21:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 10D34389851F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@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 03PCLIJf015478; Sat, 25 Apr 2020 07:21:18 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 03PCLI2p015477; Sat, 25 Apr 2020 07:21:18 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sat, 25 Apr 2020 07:21:17 -0500 From: Segher Boessenkool To: Oleg Endo Cc: Stefan Franke , gcc-help@gcc.gnu.org Subject: Re: Additional peephole pass(es) Message-ID: <20200425122117.GC17645@gate.crashing.org> References: <04d901d616fd$55668f50$0033adf0$@franke.ms> <483f01539801e24cc268be2c0adba34ada3a5e7a.camel@t-online.de> <20200424213630.GD26902@gate.crashing.org> <643ff176e1e3ab08755de5edb970996c7f8a9897.camel@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <643ff176e1e3ab08755de5edb970996c7f8a9897.camel@t-online.de> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 12:21:25 -0000 On Sat, Apr 25, 2020 at 01:04:45PM +0900, Oleg Endo wrote: > On Fri, 2020-04-24 at 16:36 -0500, Segher Boessenkool wrote: > > > > In combine itself runs split as well (one insn to two). And you can > > add instruction patterns to your machine description that are only there > > for combine: you split them to separate insns immediately again (maybe > > this is what you meant though?) > > No, that's not what I meant. What I meant was really custom "combine- > like" steps which combine would never do by itself. split1 gives you a > simple "interface" to hook into each insn without writing a full custom > pass. Ah right, the T reg passes. For GCC 11 I want to do 1-to-1 combinations as well, which helps for a bunch of things, including it can perhaps make your sett/clrt pass superfluous. We'll see :-) The treg_combine pass... I don't see why when the problem is inside a single basic block, why then combine cannot handle it? But of course most of the time it is over BB edges. Maybe fwprop or Richard's proposed new "combine2" can handle this generically? > For example, on SH I've used that to implement additional elimination > of sign/zero extending memory loads. On RX I did the same to fold some > in-memory operations, which neither combine nor peephole passes would > catch otherwise. Yeah, we need some more infrastructure to start to tackle that generically (and I'm not at all sure that that will help enough). Segher