From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15917 invoked by alias); 5 Mar 2015 19:26:58 -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 15907 invoked by uid 89); 5 Mar 2015 19:26:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_50,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; Thu, 05 Mar 2015 19:26:57 +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 t25JQt9V012787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 5 Mar 2015 14:26:55 -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 t25JQriM028156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Mar 2015 14:26:54 -0500 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t25JQgBK016082; Thu, 5 Mar 2015 16:26:42 -0300 From: Alexandre Oliva To: Richard Biener Cc: GCC Patches Subject: Re: [PR58315] reset inlined debug vars at return-to point References: Date: Thu, 05 Mar 2015 19:26:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 4 Mar 2015 16:38:13 +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-03/txt/msg00315.txt.bz2 On Mar 4, 2015, Richard Biener wrote: > Compile-time was slightly faster with the patch, 45s vs. 47s, > but the machine wasn't completely un-loaded. var-tracking parts: > unpatched: > variable tracking : 0.63 ( 1%) usr 0.03 ( 1%) sys 0.82 ( > 2%) wall 28641 kB ( 2%) ggc > var-tracking dataflow : 3.72 ( 8%) usr 0.04 ( 1%) sys 3.65 ( > 7%) wall 1337 kB ( 0%) ggc > var-tracking emit : 2.63 ( 6%) usr 0.02 ( 1%) sys 2.55 ( > 5%) wall 148835 kB ( 8%) ggc > patched: > variable tracking : 0.64 ( 1%) usr 0.01 ( 0%) sys 0.72 ( > 1%) wall 24202 kB ( 1%) ggc > var-tracking dataflow : 1.96 ( 4%) usr 0.01 ( 0%) sys 1.94 ( > 4%) wall 1326 kB ( 0%) ggc > var-tracking emit : 1.46 ( 3%) usr 0.02 ( 0%) sys 1.49 ( > 3%) wall 46980 kB ( 3%) ggc > we have at the point of RTL expansion 56% more debug statements > (988231 lines with # DEBUG in the .optimized dump out of > 1212518 lines in total vs. 630666 out of 854953). So we go from > roughly 1 debug stmt per real stmt to 1.5 debug stmts per real stmt. So, if I got this right, all these extra debug stmts and insns had no effect whatsoever on compile time proper. The reduction in compile time can be entirely accounted for by the time they save in the var-tracking parts, and any compile time increase they bring about in other passes is negligible. Does this match your assessment of the impact of the patch? > we have two pairs of DEBUG stmts for dD.570173 here, binding > to _25 and then immediately resetting. They're at different lines, and associated with different statements, so once we have stmt frontiers support in GCC and GDB, you will be able to stop between them an inspect the state, regardless of the absence of executable code between them. -- 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