From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id 8CDBE3858D1E for ; Tue, 18 Apr 2023 17:55:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8CDBE3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=axis.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=axis.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1681840509; x=1713376509; h=from:to:subject:mime-version:content-transfer-encoding: message-id:date; bh=M3K/V0X9n5D+J7f1o+4sCshlJY3ubPGYeqoU4IPk3oI=; b=YF3bcjZNexqcqZjz++xD2aeE+PQ3hBCx7Lc43aJven4Nk54PgBfiMUww aBIXsTf332Y/mxQk04/nADTIoObkSBnKUv+naRAh4MU8iLlkqsgrEXm14 ZxcRZoZb9ELOOOv8bU99acEGeFmyBP2NtqEbSdtdgWrt7l0af5Prz6Cee sXMVkyCs6k8SWZy5NWtmIVb186SdsyLKJst3y1sP1bLF8f03a6Bj5U6b2 VSitjWIpd1WVEfw9LgGDEZmxDLsb4cN2tcLLJRwug+OrdRxVzOxsOuKPs e8o0DeqKCAV3KLlct/G2d2Zf2n0dHxvNa9CbfSb6NC9IOjIkWk8GObXKW w==; From: Hans-Peter Nilsson To: 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 List-Id: 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