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 D66813959C26 for ; Fri, 24 Apr 2020 21:36:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D66813959C26 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 03OLaUOM011899; Fri, 24 Apr 2020 16:36:31 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 03OLaU53011896; Fri, 24 Apr 2020 16:36:30 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 24 Apr 2020 16:36:30 -0500 From: Segher Boessenkool To: Oleg Endo Cc: Stefan Franke , gcc-help@gcc.gnu.org Subject: Re: Additional peephole pass(es) Message-ID: <20200424213630.GD26902@gate.crashing.org> References: <04d901d616fd$55668f50$0033adf0$@franke.ms> <483f01539801e24cc268be2c0adba34ada3a5e7a.camel@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <483f01539801e24cc268be2c0adba34ada3a5e7a.camel@t-online.de> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-8.1 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: Fri, 24 Apr 2020 21:36:38 -0000 Hi! On Tue, Apr 21, 2020 at 02:34:09AM +0900, Oleg Endo wrote: > Yeah, it's true, combine doesn't catch every possible combination and > the canonical form is also sometimes questionable. Yeah. Bug reports welcome! This isn't "canonical" usually; but all targets depend more or less on what insns combine used to generate. Even for comparably tiny changes (that are a net good thing for all targets!) people become very unhappy already, so yeah it is some kinf of "de facto" canonical: but it is not that we promised this is the form we would use, and it is not that we think this is the best and we should not change it; the problem just is inertia. > You can add > additional passes in the backend as you like. If a particular > additional pass for a particular backend results in significant > improvements in code quality or such, then why not? > > You can also do "manual combine" of certain insns in the split1 pass > that runs after combine. For some examples you can browse through the > SH backend. 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?) > The problem with peepholes is that they tend to break easily because > they depend on insn order. If something else in the compiler decides > to insert insns between two related insns, peephole patterns usually > break. Another big problem is that it is very, very hard to write a *correct* (non-trivial) peephole2. Segher