From: Hans-Peter Nilsson Date: Tue, 18 Apr 2023 17:37:21 +0000 (+0200) Subject: doc: Document order of define_peephole2 scanning X-Git-Tag: basepoints/gcc-15~9609 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=07527e3eabb00ada0e7c9e083084e4e56d97f34f;p=thirdparty%2Fgcc.git doc: Document order of define_peephole2 scanning I was a bit surprised when my newly-added define_peephole2 didn't match, but it was because it was expected to partially match the generated output of a previous define_peephole2, which matched and modified the last insn of a sequence to be matched. I had assumed that the algorithm backed-up the size of the match-buffer, thereby exposing newly created opportunities *with sufficient 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. --- diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index cc4a93a87638..37e537733c94 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -9371,6 +9371,15 @@ 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 @code{define_peephole2} +appearance in the @file{md} file. After a successful replacement, +scanning for further opportunities for @code{define_peephole2}, resumes +with the first generated replacement insn as the first insn to be +matched against all @code{define_peephole2}. For the example above, +after its successful replacement, the first insn that can be matched by +a @code{define_peephole2} is @code{(set (match_dup 4) (match_dup 1))}. + @end ifset @ifset INTERNALS @node Insn Attributes