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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id EF6AC384BC17 for ; Tue, 17 Nov 2020 01:12:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EF6AC384BC17 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-572-MlYHOc2kNAq_9iDBn0DHkA-1; Mon, 16 Nov 2020 20:12:07 -0500 X-MC-Unique: MlYHOc2kNAq_9iDBn0DHkA-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 B802A1868422; Tue, 17 Nov 2020 01:12:05 +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 0CD2110013C4; Tue, 17 Nov 2020 01:12:03 +0000 (UTC) Subject: Re: CSE deletes valid REG_EQUAL? To: Segher Boessenkool Cc: Xionghu Luo , "gcc@gcc.gnu.org" , jakub@redhat.com, bonzini@gnu.org, ebotcazou@gcc.gnu.org, abel@gcc.gnu.org References: <20201113135516.GU2672@gate.crashing.org> From: Jeff Law Message-ID: Date: Mon, 16 Nov 2020 18:12:03 -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: <20201113135516.GU2672@gate.crashing.org> 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_H5, 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: Tue, 17 Nov 2020 01:12:12 -0000 On 11/13/20 6:55 AM, Segher Boessenkool wrote: > Hi guys, > > On Thu, Nov 12, 2020 at 09:10:14PM -0700, Jeff Law wrote: >> On 11/12/20 7:02 PM, Xionghu Luo via Gcc wrote: >>> 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 > The note even *always* is valid where it is! As you say, the REG_EQUAL > is only (necessarily) valid at *that* insn. And this insn *sets* the > reg (that is the only case when a REG_EQ* is allowed at all), so if the > eq reg is dead (i.e. unused) the whole insn is, and the insn can be > removed. > > Removing all REG_EQUAL notes for regs that become dead anywhere seems > to just be a thinko? All pseudos are dead somewhere! (Yeah okay, > infinite loops, but other than that.) Yea, but the code which wipes the notes probably has no sense of where in the RTL stream the note is valid and where it is not.  So it does the fairly dumb thing and just ends up wiping them all away because as you noted, most pseudos have a death somewhere.  One might argue that the code is OK as-is, but just needs to be run later.  After cse2 would be the most logical location since CSE is probably the heaviest user of the notes.  But I'd worry that the problems referenced in c#2 of bz51505 could crop up in other contexts than just combine. jeff