From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67382 invoked by alias); 20 Apr 2015 08:56:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 66761 invoked by uid 89); 20 Apr 2015 08:56:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 20 Apr 2015 08:56:02 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id EE6B08E672 for ; Mon, 20 Apr 2015 08:56:00 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-37.ams2.redhat.com [10.36.116.37]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3K8txX6017125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2015 04:56:00 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t3K8tv5E032020; Mon, 20 Apr 2015 10:55:58 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t3K8tup2032019; Mon, 20 Apr 2015 10:55:56 +0200 Date: Mon, 20 Apr 2015 08:56:00 -0000 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org, Alexandre Oliva Subject: Re: [Patch] pr65779 - [5/6 Regression] undefined local symbol on powerpc Message-ID: <20150420085556.GE1725@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20150420031049.GB12627@bubble.grove.modra.org> <20150420073507.GA1725@tucnak.redhat.com> <20150420084226.GC12627@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420084226.GC12627@bubble.grove.modra.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01000.txt.bz2 On Mon, Apr 20, 2015 at 06:12:26PM +0930, Alan Modra wrote: > I had it that way in my first patch, then decided to try deleting.. > > I can certainly change it back even if only to do it the standard way > for safety's sake, but I'm curious as to why they can't be deleted in > this special case. My thinking was that we're on a chain of blocks > starting at the entry where there is a single outgoing live edge for > the register being used. So there shouldn't be any need for a debug > insn to mark info about the variable as invalid. The debug insns can be for arbitrary variables, there is no "the variable", and there could be other debug insns for the same variable on that path, say saying that decl lives in some other register, or can be computed using an expression involving other registers, or memory etc. Say you could have (set regX (whatever)) ... (debug_insn var5 (some expression not referring to regX)) ... (debug_insn var5 (some expression referring to regX)) ... (debug_insn var5 (other expression not referring to regX)) ... (use regX) where ... contains unrelated insns (not referring to regX) and edges live for regX. If shrink wrapping attempts to move the first set somewhere into the last ..., if you delete debug insns referring to regX, you extend the lifetime of the previous debug_insn, which is wrong, the registers referenced in the first debug_insn might not contain the right values afterwards. And if you move the debug insn later, you might shorten the lifetime of the third debug_insn, while regX is supposed to contain the same value, perhaps some other register referenced there might have been changed already. Jakub