From patchwork Wed Apr 19 03:15:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 85153 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp64471vqo; Tue, 18 Apr 2023 20:16:14 -0700 (PDT) X-Google-Smtp-Source: AKy350a1q6mrF2kmJ4XWlb7Xkjty3Lc33OnivWZ6lcdhtM1CdjMHxt/xOp8PJpF8lsWLm1Llayff X-Received: by 2002:a17:906:f14f:b0:94a:a6f0:876a with SMTP id gw15-20020a170906f14f00b0094aa6f0876amr12745684ejb.1.1681874174484; Tue, 18 Apr 2023 20:16:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681874174; cv=none; d=google.com; s=arc-20160816; b=y5qrjF0AFcbVG3AHtSqjC+h8BU8OssuLcaI9wrqciSgUIiOT1vrfrxsmbQHBFiRg9Q 9xv7IrD4TTdEPg8HeU+lfl9+BBTw7g82MofE5KUpIcG0yO+QKNXe99myZR0eB2d8qqzb mSq2+mogbZC0BGwZQjaEPakVrBxILLd9xwELKe+gORC4laCe2QT2D4pYJd2//infyBP7 xhwRFbahmqq9X1ag/0bi9XT0yMNWnvnBbAc/pX2aYWg4eycGbbgH5vYKuMIzwxKYXvyg iR++jSQo3zgIJfS1I8w8AeeidYtwbrIBgb/jJrng8ReMkWqfDpdBoE0JKBSdSK0Eto3o 8bQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:date:message-id :references:content-transfer-encoding:mime-version:subject :in-reply-to:cc:to:dmarc-filter:delivered-to:dkim-signature :dkim-filter; bh=V5x2om15iUXMvFZxegmFvYdnCBC/8q47fNSa9Xq4sbs=; b=ioXf2uxzfJCbBjvAkYbioyHThBP5/7YekuQKG5aQlsauS5BdwjnlF0ZcsBvT8wohTu nk11GIw9hSUGjSPQvzKqEcMu/WpBC1+a7uoCl/BuZMT3xW1tUaEsjlKM6gEu0JN3K4+V aZlDeuVsFQVEwgAJufo8XYoikRpqz1sBksi3tfwkqJBkrcjaq4pVBjqpXN5nb9IaZSwR JewnpZgE/ymhou9VY65xuQOK9nvrB79e5qBINEd+zBP6v30midjWwmTQ7IZRKWcEM/+0 0/8OZ7TFvWRX3/aAjR/O8zKQ06/bBJp5tLhzbAug57I22c8DmjXZYRN7c9n3iYIlOiXw U91g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="ZSe/g9EQ"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id vl6-20020a17090730c600b0094f7daa896fsi5097779ejb.314.2023.04.18.20.16.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 20:16:14 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="ZSe/g9EQ"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 249173858D28 for ; Wed, 19 Apr 2023 03:16:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 249173858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681874173; bh=V5x2om15iUXMvFZxegmFvYdnCBC/8q47fNSa9Xq4sbs=; h=To:CC:In-Reply-To:Subject:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=ZSe/g9EQ1KxWzUV5fl5yNkFjgwhTxT0LUFHdE81gFkHFQxReEelDNPHlIuOKPaewn IkoOU55zDHmbWPTn6T3lEqEZfmukc2MQFlu79p+/mSQRNUQJH9GoV6jIONvw6B0fjy b75mWOYzNH3Cp+THbWtG7++VZsUMe9KM65z4sPSE= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id 1785D3858D1E for ; Wed, 19 Apr 2023 03:15:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1785D3858D1E To: CC: In-Reply-To: <20230418184412.95E632043B@pchp3.se.axis.com> (message from Hans-Peter Nilsson on Tue, 18 Apr 2023 20:44:12 +0200) Subject: [PATCH v2] doc: Document order of define_peephole2 scanning MIME-Version: 1.0 References: <20230418175507.2C40B2040B@pchp3.se.axis.com> <0442F4ED-45A1-44D3-AB1B-F28657F04D3F@comcast.net> <20230418184412.95E632043B@pchp3.se.axis.com> Message-ID: <20230419031527.6D39120420@pchp3.se.axis.com> Date: Wed, 19 Apr 2023 05:15:27 +0200 X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Hans-Peter Nilsson via Gcc-patches From: Hans-Peter Nilsson Reply-To: Hans-Peter Nilsson Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763537639324768219?= X-GMAIL-MSGID: =?utf-8?q?1763572894662216312?= > From: Hans-Peter Nilsson > Date: Tue, 18 Apr 2023 20:44:12 +0200 > > > From: Paul Koning > > > Date: Tue, 18 Apr 2023 14:32:07 -0400 > > > > I'm not sure about the meaning of part of this. > > "...resumes at the last generated insn." Does that mean: [...] > (Neither...) [...] > Sorry, your confusement confuses me. I just don't see how > to confuse last with first or matched with generated. :) It's 4:30am and things appear much clearer, in particular wrt. confusion. Hopefully the version below is clearer. Here's also the example from 35 lines up in md.texi: (define_peephole2 [(match_scratch:SI 4 "r") (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) (set (match_operand:SI 2 "" "") (match_dup 1)) (match_dup 4) (set (match_operand:SI 3 "" "") (match_dup 1))] "/* @r{determine 1 does not overlap 0 and 2} */" [(set (match_dup 4) (match_dup 1)) (set (match_dup 0) (match_dup 4)) (set (match_dup 2) (match_dup 4)) (set (match_dup 3) (match_dup 4))] "") Approvers: pdf output reviewed. Ok to commit? All: thoughts on making define_peephole2 work "as expected"; "backtracing" so the replacement buffer ends with the first generated replacement insn? Might be simpler to restart at the beginning of the BB, but I'm scared of overly long BB's. Does anyone have statistics on the sizes of BB's in terms of number of insns? -- >8 -- I was a bit surprised when my define_peephole2 didn't match, but it was because it was expected to partially match the generated output of a previous define_peephole2. I had assumed that the algorithm backed-up the size of the match-buffer, thereby exposing newly created opportunities with context to all define_peephole2's. While things can change in that direction, let's start with documenting the current state. * doc/md.texi (define_peephole2): Document order of scanning. --- gcc/doc/md.texi | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index 07bf8bdebffb..2ce043e6edc2 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -9362,6 +9362,14 @@ If the preparation falls through (invokes neither @code{DONE} nor @code{FAIL}), then the @code{define_peephole2} uses the replacement template. +Insns are scanned in forward order from beginning to end for each basic +block. Matches are attempted in order of appearance in the @file{md} +file. After a successful replacement, scanning for further +opportunities for @code{define_peephole2}, resumes with the last +generated replacement insn as the first insn to be matched. For the +example above, the first insn that can be matched by another +@code{define_peephole2}, is @code{(set (match_dup 3) (match_dup 4))}. + @end ifset @ifset INTERNALS @node Insn Attributes