Message ID | 20230418175507.2C40B2040B@pchp3.se.axis.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> 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 373903858D39 for <patchwork@sourceware.org>; Tue, 18 Apr 2023 17:55:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 373903858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681840536; bh=M3K/V0X9n5D+J7f1o+4sCshlJY3ubPGYeqoU4IPk3oI=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=oLsFKwQ3rcXfsoF71ZGxuJwGTzQ4B7fIS4jIO0qWG93z/icIRKgR6uFy4PIMxD/OR K8/NbjALLqBNvW7i1pz2FCj6UBmigY0VCAC9c3beBwGc3M525g/aoTF4H8zjbbvvSH bHdUdy8vKMbOmrZCy/5//S8MvxjetjJf5NSFnXvc= 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 8CDBE3858D1E for <gcc-patches@gcc.gnu.org>; Tue, 18 Apr 2023 17:55:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8CDBE3858D1E To: <gcc-patches@gcc.gnu.org> Subject: [PATCH] doc: Document order of define_peephole2 scanning MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-ID: <20230418175507.2C40B2040B@pchp3.se.axis.com> Date: Tue, 18 Apr 2023 19:55:07 +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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Hans-Peter Nilsson <hp@axis.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
doc: Document order of define_peephole2 scanning
|
|
Commit Message
Hans-Peter Nilsson
April 18, 2023, 5:55 p.m. UTC
Generated pdf inspected. Ok to commit? Thoughts on fixing the IMHO wart to also expose all replacements to all define_peephole2? Looks feasible (famous last words), but then again I haven't checked the history yet. -- >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 exposed newly created opportunities 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(+)
Comments
I'm not sure about the meaning of part of this. "...resumes at the last generated insn." Does that mean: 1. If a match is found at some insn, the replacement defined by the matching define_peephole2 is performed, and then the scan resumes at the first of the insns produced by the replacement. or 2. If a match is found at some insn, the replacement defined by the matching define_peephole2 is performed, and then the scan resumes at the insn immediately following the ones just matched. "Last generated" seems to fit option 1, but I'm not sure if that's what you meant. Maybe you could add some words to say more explicitly which it is. paul > On Apr 18, 2023, at 1:55 PM, Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Generated pdf inspected. Ok to commit? > > Thoughts on fixing the IMHO wart to also expose all > replacements to all define_peephole2? Looks feasible > (famous last words), but then again I haven't checked the > history yet. > > -- >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 exposed newly created opportunities > 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..0f9e32d2c648 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, but the basic blocks are scanned in reverse order of appearance > +in a function. After a successful replacement, scanning for further > +opportunities for @code{define_peephole2} matches, resumes at the last > +generated insn. I.e. 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 > -- > 2.30.2 >
> From: Paul Koning <paulkoning@comcast.net> > 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...) > 1. If a match is found at some insn, the replacement > defined by the matching define_peephole2 is performed, and > then the scan resumes at the first of the insns produced > by the replacement. This was what I expected. If it had been this, I wouldn't have suggested the doc update. But it isn't: no, it's the *last produced one*. If you look at the referenced example (unfortunately outside of the diff context) it should all be clear. > or > > 2. If a match is found at some insn, the replacement > defined by the matching define_peephole2 is performed, and > then the scan resumes at the insn immediately following > the ones just matched. No, from the last of the replacement insns. > "Last generated" seems to fit option 1, Sorry, your confusement confuses me. I just don't see how to confuse last with first or matched with generated. :) > but I'm not sure > if that's what you meant. Maybe you could add some words > to say more explicitly which it is. I'm referring to an example on the same pdf page. But perhaps s/resumes at the last generated insn/resumes at the last insn in the replacement sequence/ would help? brgds, H-P > > paul > > > On Apr 18, 2023, at 1:55 PM, Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > > Generated pdf inspected. Ok to commit? > > > > Thoughts on fixing the IMHO wart to also expose all > > replacements to all define_peephole2? Looks feasible > > (famous last words), but then again I haven't checked the > > history yet. > > > > -- >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 exposed newly created opportunities > > 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..0f9e32d2c648 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, but the basic blocks are scanned in reverse order of appearance > > +in a function. After a successful replacement, scanning for further > > +opportunities for @code{define_peephole2} matches, resumes at the last > > +generated insn. I.e. 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 > > -- > > 2.30.2 > > >
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index 07bf8bdebffb..0f9e32d2c648 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, but the basic blocks are scanned in reverse order of appearance +in a function. After a successful replacement, scanning for further +opportunities for @code{define_peephole2} matches, resumes at the last +generated insn. I.e. 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