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: 67976 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 12EDB3858D28 for ; Wed, 19 Apr 2023 03:15:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12EDB3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681874158; 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=JOIViMCkuOGjdl0jQaNpB+UfnWCF2eBEN65mzs0sUjIniZW9meH3GRYfreG+NA48b av43iVFiI1yO0oVakl6t0sDuQs01uo3ahN+Og75l0/MUCt3WqFuVygmo14X9q/FPs2 bhOxZZ3kp3yEvMwFJISfeuz59JW7hnN9WelSev6c= 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+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" > 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