From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <oleg.endo@t-online.de>
Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19])
 by sourceware.org (Postfix) with ESMTPS id 3828F385DC26
 for <gcc-help@gcc.gnu.org>; Sat, 25 Apr 2020 04:04:51 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3828F385DC26
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=t-online.de
Authentication-Results: sourceware.org;
 spf=none smtp.mailfrom=oleg.endo@t-online.de
Received: from fwd13.aul.t-online.de (fwd13.aul.t-online.de [172.20.27.62])
 by mailout06.t-online.de (Postfix) with SMTP id C0EF841CF5AC;
 Sat, 25 Apr 2020 06:04:49 +0200 (CEST)
Received: from localhost.localdomain
 (Tl0rJUZfghDFDR-Fpcx0IBv8ze1KVq3AEHr5iwYA7wpLdWpYnsKi2p6CIQkQ7aVZ8n@[115.165.108.210])
 by fwd13.t-online.de
 with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted)
 esmtp id 1jSC3d-0BBmOO0; Sat, 25 Apr 2020 06:04:49 +0200
Message-ID: <643ff176e1e3ab08755de5edb970996c7f8a9897.camel@t-online.de>
Subject: Re: Additional peephole pass(es)
From: Oleg Endo <oleg.endo@t-online.de>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Stefan Franke <stefan@franke.ms>, gcc-help@gcc.gnu.org
Date: Sat, 25 Apr 2020 13:04:45 +0900
In-Reply-To: <20200424213630.GD26902@gate.crashing.org>
References: <04d901d616fd$55668f50$0033adf0$@franke.ms>
 <483f01539801e24cc268be2c0adba34ada3a5e7a.camel@t-online.de>
 <20200424213630.GD26902@gate.crashing.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-ID: Tl0rJUZfghDFDR-Fpcx0IBv8ze1KVq3AEHr5iwYA7wpLdWpYnsKi2p6CIQkQ7aVZ8n
X-TOI-MSGID: 40ee2b5f-e983-4876-9ea9-27415e55bfb1
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, FREEMAIL_FROM,
 KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE,
 TXREP 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 <gcc-help.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Apr 2020 04:04:52 -0000

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.

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.

> Another big problem is that it is very, very hard to write a *correct*
> (non-trivial) peephole2.
> 

I agree.  Combine patterns are easier to deal with.

Cheers,
Oleg