From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121319 invoked by alias); 25 Feb 2015 21:18:02 -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 121200 invoked by uid 89); 25 Feb 2015 21:18:01 -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,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; Wed, 25 Feb 2015 21:17:59 +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 t1PLHwqL010103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Feb 2015 16:17:58 -0500 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 t1PLHttJ006145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Feb 2015 16:17:57 -0500 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t1PLHYAS028102; Wed, 25 Feb 2015 18:17:35 -0300 From: Alexandre Oliva To: Jakub Jelinek Cc: Richard Biener , GCC Patches Subject: Re: [PR58315] reset inlined debug vars at return-to point References: <20150225161256.GT1746@tucnak.redhat.com> Date: Wed, 25 Feb 2015 21:22:00 -0000 In-Reply-To: <20150225161256.GT1746@tucnak.redhat.com> (Jakub Jelinek's message of "Wed, 25 Feb 2015 17:12:56 +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/msg01545.txt.bz2 On Feb 25, 2015, Jakub Jelinek wrote: > various tools and users really want to > be able to inspect variables and parameters on the return statement. This patch won't affect the return statement. The resets are at the return-to statement; if you stop at the return statement (assuming you have code generated for it in place), you should still get the same bindings. Now, if *all* the code for the return statement was optimized away, and you stop at the subsequent instruction, that happens to be past the return, then, yeah, you're out of luck, but then you were already out of luck before. Now, there is of course the case in which there is some code left in place for the return stmt, but it is no longer in its natural position in the code flow. You stop there, you're technically out of the inline scope, but now you're also past the "clobbering" of the inlined variables. The real solution for this is to implement the stmt frontiers I presented at some GCC Summit, so that, when you stop at a statement, you get the state you expect regardless of code motion, because you get the state at the natural flow of control, even if node actual code remained at that point. > And another thing is the amount of the added debug stmts, right now we don't > add debug stmts all the time for everything, just when something is needed, We add debug stmts whenever a trackable (auto "gimple register") variable is modified. They are "clobbered" at the end of the inline function they expanded out of, so this just corrects an long-standing and quite expensive oversight. You won't get debug stmts for unused inlined variables, for example: you should only get them for variables that were remapped while inlining the code to begin with. If you got code for them and they are trackable, you certainly got debug stmts for them as well. > while your patch adds it unconditionally, even when debug stmts for those > won't be really emitted. It shouldn't. Please show me? > As they are just resets, that hopefully will not > drastically affect var-tracking time They will. But in a positive way :-) > but might affect other optimization passes, which would need to deal > with much more statements than before. It shouldn't be hard to test this hypothesis one way or another. Tweak the code that introduces the new debug temps so that they all refer to the same fake variable, as opposed to resetting the intended variables, and then you'll have an exact measure of the compile-time impact *without* the savings afforded by the resets. Then we can compare whether it's an overall win or loss. 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? -- 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