> From: Hans-Peter Nilsson <h...@axis.com> > Date: Wed, 19 Apr 2023 18:59:14 +0200 [...]
> So again: Approvers: pdf output reviewed. Ok to commit? > -- >8 -- > 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. > --- > gcc/doc/md.texi | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi > index 07bf8bdebffb..300d104d58ab 100644 > --- a/gcc/doc/md.texi > +++ b/gcc/doc/md.texi > @@ -9362,6 +9362,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 > -- > 2.30.2 >