From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 0CE2738708E0 for ; Fri, 13 Nov 2020 04:11:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0CE2738708E0 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-315-tkt8dQmQO_Cv_D-i128mqw-1; Thu, 12 Nov 2020 23:11:07 -0500 X-MC-Unique: tkt8dQmQO_Cv_D-i128mqw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1EDFA95A7A9; Fri, 13 Nov 2020 04:10:23 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-176.phx2.redhat.com [10.3.112.176]) by smtp.corp.redhat.com (Postfix) with ESMTP id 81D531002C0C; Fri, 13 Nov 2020 04:10:16 +0000 (UTC) Subject: Re: CSE deletes valid REG_EQUAL? To: Xionghu Luo , "gcc@gcc.gnu.org" Cc: jakub@redhat.com, bonzini@gnu.org, segher Boessenkool , ebotcazou@gcc.gnu.org, abel@gcc.gnu.org References: From: Jeff Law Message-ID: Date: Thu, 12 Nov 2020 21:10:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 04:11:13 -0000 On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote: > Hi all, > > In PR51505(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505), Paolo Bonzini > added the code to delete REG_EQUAL notes in df_remove_dead_eq_notes: > > gcc/df-problems.c: > df_remove_dead_eq_notes (rtx_insn *insn, bitmap live) > { > ... > case REG_EQUAL: > case REG_EQUIV: > { > /* Remove the notes that refer to dead registers. As we have at most > one REG_EQUAL/EQUIV note, all of EQ_USES will refer to this note > so we need to purge the complete EQ_USES vector when removing > the note using df_notes_rescan. */ > df_ref use; > bool deleted = false; > > FOR_EACH_INSN_EQ_USE (use, insn) > if (DF_REF_REGNO (use) >= FIRST_PSEUDO_REGISTER > && DF_REF_LOC (use) > && (DF_REF_FLAGS (use) & DF_REF_IN_NOTE) > && !bitmap_bit_p (live, DF_REF_REGNO (use)) > && loc_mentioned_in_p (DF_REF_LOC (use), XEXP (link, 0))) > { > deleted = true; > break; > } > if (deleted) > { > rtx next; > if (REG_DEAD_DEBUGGING) > df_print_note ("deleting: ", insn, link); > next = XEXP (link, 1); > free_EXPR_LIST_node (link); > *pprev = link = next; > df_notes_rescan (insn); > } > ... > } > > > while I have a test case as below: > > > typedef long myint_t; > __attribute__ ((noinline)) myint_t > hash_loop (myint_t nblocks, myint_t hash) > { > int i; > for (i = 0; i < nblocks; i++) > hash = ((hash + 13) | hash) + 0x66546b64; > return hash; > } > > before cse1: > > 22: L22: > 16: NOTE_INSN_BASIC_BLOCK 4 > 17: r125:DI=r120:DI+0xd > 18: r118:DI=r125:DI|r120:DI > 19: r126:DI=r118:DI+0x66540000 > 20: r120:DI=r126:DI+0x6b64 > REG_EQUAL r118:DI+0x66546b64 > 21: r119:DI=r119:DI-0x1 > 23: r127:CC=cmp(r119:DI,0) > 24: pc={(r127:CC!=0)?L22:pc} > REG_BR_PROB 955630228 > > The dump in cse1: > > 16: NOTE_INSN_BASIC_BLOCK 4 > 17: r125:DI=r120:DI+0xd > 18: r118:DI=r125:DI|r120:DI > REG_DEAD r125:DI > REG_DEAD r120:DI > 19: r126:DI=r118:DI+0x66540000 > REG_DEAD r118:DI > 20: r120:DI=r126:DI+0x6b64 > REG_DEAD r126:DI > 21: r119:DI=r119:DI-0x1 > 23: r127:CC=cmp(r119:DI,0) > 24: pc={(r127:CC!=0)?L22:pc} > REG_DEAD r127:CC > REG_BR_PROB 955630228 > ; pc falls through to BB 6 > > > The output shows "REQ_EQUAL r118:DI+0x66546b64" is deleted by df_remove_dead_eq_notes, > but r120:DI is not REG_DEAD here, so is it correct here to check insn use and find that > r118:DI is dead then do the delete? It doesn't matter where the death occurs, any REG_DEAD note will cause the REG_EQUAL note to be removed.  So given the death note for r118, then any REG_EQUAL note that references r118 will be removed.  This is overly pessimistic as the note may still be valid/useful at some points.  See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92291 Jeff ps.  Note that a REG_EQUAL note is valid at a particular point in the IL -- it is not a function-wide equivalence.  So you have to be careful using such values as they can be invalidated by other statements.  Contrast to a REG_EQUIV note where the equivalence is global and you don't have to worry about invalidation.