> From: Hans-Peter Nilsson <h...@axis.com>
> Date: Wed, 19 Apr 2023 06:06:27 +0200
>
> Patch retracted, at least temporarily. My "understanding"
> may be clouded by looking at an actual bug. Sigh.
Mea culpa. I was looking at the result of one
define_peephole2 and thinking it was due to another, and
also tricked by incorrect code comments (patch posted, will
commit).
TL;DR: Matching indeed does resume with attempting to match
the *first* define_peephole2 replacement insn. But the
match-and-replacement order is largely undocumented.
Anyway, the missing-context problem I ran into remains: if
you have an insn sequence {foo bar} and a define_peephole2
matching and replacing {bar} into {baz}, the resulting {foo
baz} *will not be matched* against a define_peephole2
looking for {foo baz}. But, I'm not trying to document this
caveat specifically, though at least it'll now be implied by
the documentation.
This could be fixed by always backing up MAX_INSNS_PER_PEEP2
- 1 insns after a successful replacement. I'm somewhat
worries that this would also mean lots of futile re-match
attempts. Thoughts?
(I could also just restart at the BB start, but I see all
this support for backing-up live info by single insns being
used. Taking notes about a partial match for the first insn
of a failed attempt, as the maximum need to back-up to,
doesn't look like it'd fly, judging from the nonspecific
looking (set dest src) patterns being the first in i386
define_peephole2's match sequences.)
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
