From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64067 invoked by alias); 26 Feb 2015 10:29:39 -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 64058 invoked by uid 89); 26 Feb 2015 10:29:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f173.google.com Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 26 Feb 2015 10:29:37 +0000 Received: by mail-ob0-f173.google.com with SMTP id uy5so9946994obc.4 for ; Thu, 26 Feb 2015 02:29:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.204.88 with SMTP id c85mr5052534oig.81.1424946575379; Thu, 26 Feb 2015 02:29:35 -0800 (PST) Received: by 10.76.98.137 with HTTP; Thu, 26 Feb 2015 02:29:35 -0800 (PST) In-Reply-To: References: <20150225161256.GT1746@tucnak.redhat.com> <20150225212231.GX1746@tucnak.redhat.com> Date: Thu, 26 Feb 2015 10:46:00 -0000 Message-ID: Subject: Re: [PR58315] reset inlined debug vars at return-to point From: Richard Biener To: Alexandre Oliva Cc: Jakub Jelinek , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg01586.txt.bz2 On Thu, Feb 26, 2015 at 1:01 AM, Alexandre Oliva wrote: > On Feb 25, 2015, Jakub Jelinek 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. > > 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. > > This, in turn, suggests that introducing reset stmts when variables go > out of scope even in local blocks will further reduce debug info, > although in some cases it might have the opposite effect. E.g., if the > actual live range of a variable is scattered across multiple > non-contiguous blocks, stopping the binding from being used in > intervening blocks where the variable is not live will cause additional > entries in the location list. I've observed this effect with the > proposed patch, too, but it removes a lot more nonsensical entries than > it adds entries to account for not covering intervening ranges by > accident. Answering your questions on my mail here (because it fits I think), and more concentrating on the effect of your patch as opposed to debug stmt philosophy. Your patch ends up pruning the var-tracking sets at the additional reset-points you introduce. You introduce them at inline boundaries (which looks reasonable minus code-motion issues). I claim you can achieve the same result by effectively inserting those reset debug insns right before var-tracking itself and by re-computing BLOCK "liveness". That will automatically deal with code motion that extends the life-range of an inlined BLOCK by moving stmts (still associated with that BLOCK) across the return point of the inlined call (and thus across your debug resets). And it will allow var-tracking to eventually compute locations for vars at the "entry" of that BLOCK piece. After all you say correctly that what matters is location info for X in places where a debug consumer can successfully lookup X (that is, in PC ranges where the scope X was declared in is active). In other places there is no reason to emit location info for X (but we might still want to compute it during var-tracking if at a later PC range the scope will be active again). Now I said you could do var-tracking uops for those resets somehow, but I now realize that I have not much internal knowledge of var-tracking. Thus consider the suggestion to insert reset debug insns at the beginning of var-tracking and at points where a scope becomes dead (thus after points where in a backward CFG walk a scope becomes live). Richard. > -- > 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