From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28838 invoked by alias); 25 Feb 2015 21:02:21 -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 28823 invoked by uid 89); 25 Feb 2015 21:02:20 -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; Wed, 25 Feb 2015 21:02:19 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1PL2He1028438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Feb 2015 16:02:17 -0500 Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1PL2Ah7017403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Feb 2015 16:02:16 -0500 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t1PL1x5k025444; Wed, 25 Feb 2015 18:02:00 -0300 From: Alexandre Oliva To: Richard Biener Cc: GCC Patches Subject: Re: [PR58315] reset inlined debug vars at return-to point References: Date: Wed, 25 Feb 2015 21:13:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 25 Feb 2015 11:54:16 +0100") 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-02/txt/msg01542.txt.bz2 On Feb 25, 2015, Richard Biener wrote: > But code-motion could still move stmts from the inlined functions > across these resets? Sure, just like it could still move stmts across any other debug stmts. Once you return from a function, it's as if all of its variables ceased to exist, so what is the problem with this? The real error, IMHO, is to assume the moved instruction is still inside the inline function. It isn't. If you wanted to inspect the variable before it went out of scope, the debugger should have helped you stop there, not stop you at an instruction that is outside the expected flow. > That said - shouldn't this simply performed by proper var-tracking > u-ops produced by a backward scan over the function for "live" > scope-blocks? Please elaborate (ideally with a patch); I have no idea of how you plan to map scope blocks to their original (and thus correct) position (i.e., before any code motion). > That is, when you see a scope block becoming live from exit then add > u-ops resetting all vars from that scope block? Oh, you want code motion artifacts to leak into the language VM execution modeled in debug info? That would be fundamentally against the model implemented with debug stmts and insns. /me mumbles something about mixing metaphors and leaky screwdrivers ;-D IOW, I don't think that would be appropriate at all. Remember the VTA presentation at the GCC Summit years ago, when I showed you just can't hope to recover debug info from code already mangled by the compiler, because optimizations are lossy? You get to a point in which you don't know what you don't know, so you're bound to make wrong decisions. So, take note of what you're going to need when you know it's still accurate. > Your patch as-is would add very many debug stmts to for example > tramp3d. Do you have any evidence that this would have a negative impact on compile time, memory use or any other relevant metric? Odds are that, if it makes any difference whatsoever, it will be a very positive one. The absolute worst case of this patch is doubling the debug stmt count (proof: it will add at most one debug stmt per inlined variable that had at least one debug stmt). Now, if you're concerned about debug stmt count, we could introduce another debug stmt/insn form that can reset multiple variables in a single swoop. It does not seem to me like this would be worth the effort. > And as you say, the same reasoning applies to scopes in general, not > just for inlines. I actually said the opposite. We turn block-local variables into function-wide declarations very early, so apparently we *can* reference the variables even when they're out of scope. But we *cannot* do that for inlined variables. That's why I drew the line where I did. (Plus, introducing the debug temps at the point I did was easy to try, and it had a huge positive impact :-) Sure we *could* introduce debug unbind stmts at the end of scopes. If you have evidence or even a hunch that this will have a positive effect on relevant metrics, go for it! -- 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