From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31416 invoked by alias); 26 Feb 2015 07:23:22 -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 31406 invoked by uid 89); 26 Feb 2015 07:23:22 -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,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; Thu, 26 Feb 2015 07:23:21 +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 (8.14.4/8.14.4) with ESMTP id t1Q7NJS3025592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 26 Feb 2015 02:23:19 -0500 Received: from tucnak.zalov.cz (ovpn-116-28.ams2.redhat.com [10.36.116.28]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1Q7NHVE009874 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 26 Feb 2015 02:23:18 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t1Q7NGIA025418; Thu, 26 Feb 2015 08:23:17 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t1Q7NFxP025417; Thu, 26 Feb 2015 08:23:15 +0100 Date: Thu, 26 Feb 2015 07:37:00 -0000 From: Jakub Jelinek To: Alexandre Oliva , Petr Machata Cc: Richard Biener , GCC Patches Subject: Re: [PR58315] reset inlined debug vars at return-to point Message-ID: <20150226072315.GZ1746@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20150225161256.GT1746@tucnak.redhat.com> <20150225212231.GX1746@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg01570.txt.bz2 On Wed, Feb 25, 2015 at 09:01:09PM -0300, Alexandre Oliva wrote: > > On Wed, Feb 25, 2015 at 06:17:33PM -0300, Alexandre Oliva wrote: > >> My measurements, for a not particularly unusual testcase, showed an > >> overall reduction of 63% in compile time, as indicated yesterday. Now, > >> who should bear the burden of collecting evidence to back up the claims > >> against the change? Are those concerns enough to hold it up? > > > Can you e.g. run dwlocstat on some larger C++ binaries built without and > > with your patch? I believe dwlocstat is supposed to count only the > > instructions where the variables or parameters are in scope, so should be > > exactly what we care about here. > > Erhm... I don't think that would cover the case you were worried about, > namely inspecting variables of an inlined function while at a statement > moved out of the function ranges. > > Anyway, I've run dwlocstat and inspected the results. There is indeed a > significant reduction in the coverage, so I looked into that. Significant reduction in the coverage should be a red flag. I admit I haven't read dwlocstat sources recently, but: dwlocstat ========= This is a tool for examining Dwarf location info coverage. It goes through DIEs of given binary's debug info that represent variables and function parameters. For each such DIE, it computes coverage of that DIE's range (list of addresses of DIE's scope) by location expressions (a description of where given variable is located at given location: e.g. a variable can be in a register). matches what I wanted the tool to do, namely, if you have say some DW_TAG_variable that is in scope of say an inline function and that DW_TAG_inlined_subroutine has DW_AT_ranges L1-L2, L3-L4, L5-L6, it counts on what percentage of bytes in those ranges (or instructions?) the variable has defined location. The fear I have is that due to scheduling or any other code motion toward the end of function, you simply have instructions like L5-L6 above that are considered part of the function, but that the newly added resets are say on L4 or so and thus whenever you stop on the L5-L6 instructions, the debugger will show you you are in the inline function, but you won't be able to inspect most if not any variables. > What I found out is that the reduction is an improvement on yet another > long-standing var-tracking issue: if a function is called within a loop > and we inline it, bindings from the call in one iteration of the loop > will carry over onto the subsequent iteration until a new binding > occurs. This accounts for all of the coverage reductions I've > investigated. It really depends. Say if you have some inline void foo (void) { int somevar; LARGE CODE NOT INITIALIZING somevar; somevar = VALUE; USE somevar; } and for (...) { foo (); } and the loop is unrolled, then indeed, lost of coverage between the start of the second foo and somevar = VALUE; is acceptable, if it previously just contained the value from previous iteration. But as I said above, if it is about the last few stmts in the inline scope, it is undesirable, and if e.g. the instructions from different unrolled iterations are intermixed, then it is undesirable too. Which is why I was suggesting special debug binds that the optimizers would try to move downward (towards the exit block) on (as much as possible) any code motions across them, unless the debug binds would be moved across a debug bind for the same decl - in that case the end of scope debug bind should be removed rather than moved over. In most cases, there won't be much of code motion across the whole function, but only limited scope, so in the common case you'll still get the effect you are looking for or close to that, but it won't actually penalize the debug info quality. Jakub