From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80102 invoked by alias); 10 Mar 2015 16:35:33 -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 80092 invoked by uid 89); 10 Mar 2015 16:35:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_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; Tue, 10 Mar 2015 16:35:31 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2AGZT24002640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 10 Mar 2015 12:35:29 -0400 Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2AGZQSq022557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Mar 2015 12:35:28 -0400 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t2AGZKh9014175; Tue, 10 Mar 2015 13:35:20 -0300 From: Alexandre Oliva To: Jeff Law Cc: Richard Biener , Jakub Jelinek , Petr Machata , GCC Patches Subject: Re: [PR58315] reset inlined debug vars at return-to point References: <20150225161256.GT1746@tucnak.redhat.com> <20150225212231.GX1746@tucnak.redhat.com> <20150226072315.GZ1746@tucnak.redhat.com> <54FDD5C3.5090301@redhat.com> Date: Tue, 10 Mar 2015 16:35:00 -0000 In-Reply-To: <54FDD5C3.5090301@redhat.com> (Jeff Law's message of "Mon, 09 Mar 2015 11:17:55 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-03/txt/msg00579.txt.bz2 On Mar 9, 2015, Jeff Law wrote: > On 03/09/15 08:38, Richard Biener wrote: >> On Fri, Mar 6, 2015 at 7:04 PM, Alexandre Oliva wrote: >>> On Feb 26, 2015, Alexandre Oliva wrote: >>> >>>> So far, all the differences I looked at were caused by padding at the >>>> end of BBs, and by jump stmts without line numbers at the end of BBs, >>>> both right after the debug reset stmts the proposed patch introduces. >>> >>> Further investigation showed there were other sources of spurious >>> differences: >>> >>> - copies arising from the expansion of PHI nodes; source code >>> information associated with these copies points at the source of the >>> copy, which is hardly useful and sensible. >> >> Care to explain? We spend quite some resources to maintain them >> (locations on PHI args, that is). The situation I remember, for looking more extensively into, involved a variable local to the inlined function, a copy of that variable to a caller's variable, and that caller's variable being further modified elsewhere. We coalesced the two variables into one, removed the copy statement altogether, and the location from the initial set within the inline function made it to PHI nodes related with the caller's variable, and that survived various PHI recomputations due to various CFG reorganizations. When the time came to expand the PHI nodes, copies were required and line number info internal to the inlined function was added to the copy arising from the edge that had in it the SSA name set inside the inline function. And so the ranges of the inline function were extended far past its actual end, because a coalesced copy from one of its variables was optimized away and then reintroduced with line number info pertaining to the inlined function. > I almost responded to that claim as well, but then thought better of > it as that patch (AFAICT) wasn't proposed for inclusion, but was being > used for testing purposes. The patch that removed line number annotation from copies arising from expanding PHI nodes was included only for reference, yes. The upthread patch for PR58315 still stands. > Expansion of the PHI into copies should have locations which point to > the source of the various PHI args. Those are quite meaningful. I can see those can be meaningful in many cases. Not in the ones I looked at as part of investigating the coverage changes, though. We have a substantial number of copies that arise from processes like the one I described above, and those are most certainly not sensible, mainly because the relevant line number info was dropped on the floor along with copies optimized away due to coalescing of variables from different scopes. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer