From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <oleg.endo@t-online.de>
Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20])
 by sourceware.org (Postfix) with ESMTPS id 1C1F13858D31
 for <gcc-help@gcc.gnu.org>; Mon, 20 Apr 2020 17:34:21 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1C1F13858D31
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 fwd39.aul.t-online.de (fwd39.aul.t-online.de [172.20.27.138])
 by mailout08.t-online.de (Postfix) with SMTP id 80E76414EB10;
 Mon, 20 Apr 2020 19:34:19 +0200 (CEST)
Received: from localhost.localdomain
 (Gz2lr+ZSwh4aUiUt5O6Dh2srGJ04C8PoSzgxghGE6pTcukNZynC1-1AS0bAZBxbgKk@[115.165.108.210])
 by fwd39.t-online.de
 with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted)
 esmtp id 1jQaJB-4X6enY0; Mon, 20 Apr 2020 19:34:13 +0200
Message-ID: <483f01539801e24cc268be2c0adba34ada3a5e7a.camel@t-online.de>
Subject: Re: Additional peephole pass(es)
From: Oleg Endo <oleg.endo@t-online.de>
To: Stefan Franke <stefan@franke.ms>, gcc-help@gcc.gnu.org
Date: Tue, 21 Apr 2020 02:34:09 +0900
In-Reply-To: <04d901d616fd$55668f50$0033adf0$@franke.ms>
References: <04d901d616fd$55668f50$0033adf0$@franke.ms>
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: Gz2lr+ZSwh4aUiUt5O6Dh2srGJ04C8PoSzgxghGE6pTcukNZynC1-1AS0bAZBxbgKk
X-TOI-MSGID: a9a52dc3-15b2-4e6c-b32e-613beb0ed63e
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM,
 KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Mon, 20 Apr 2020 17:34:22 -0000

Hi,

On Mon, 2020-04-20 at 12:20 +0200, Stefan Franke wrote:
> 
> is there a chance that a patch would be accepted if it adds (an) additional
> peephole pass(es)?
>  
> 
> I'm not content with the capabilities of the combine pass and a convenient
> way would be to insert an additional pass in front/after the combine pass.
> It's way easier to maintain than the spaghetti code in combine and ss long
> there is nothing defined in the cpu's md file, the pass gets skipped, so the
> overhead for non-users is almost non existent.
>  
> 
> Right now I'm applying the same set as in the final peephole run, but I
> would add a separate keyword per pass, e.g. peephole_precombine, etc. p.p.
>  
> 
> Your thoughts?
> 

Yeah, it's true, combine doesn't catch every possible combination and
the canonical form is also sometimes questionable.  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.

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.

Cheers,
Oleg