From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118836 invoked by alias); 25 Feb 2015 16:16:25 -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 118822 invoked by uid 89); 25 Feb 2015 16:16:24 -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,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 16:16:23 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1PGGHCG006251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Feb 2015 11:16:21 -0500 Received: from tucnak.zalov.cz (ovpn-116-28.ams2.redhat.com [10.36.116.28]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1PGCxDt004543 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Feb 2015 11:13:00 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t1PGCvk3007651; Wed, 25 Feb 2015 17:12:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t1PGCupG007650; Wed, 25 Feb 2015 17:12:56 +0100 Date: Wed, 25 Feb 2015 16:28:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Alexandre Oliva , GCC Patches Subject: Re: [PR58315] reset inlined debug vars at return-to point Message-ID: <20150225161256.GT1746@tucnak.redhat.com> Reply-To: Jakub Jelinek References: 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/msg01516.txt.bz2 On Wed, Feb 25, 2015 at 11:54:16AM +0100, Richard Biener wrote: > > Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install? > > But code-motion could still move stmts from the inlined functions > across these resets? 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? That is, when you see a scope > block becoming live from exit then add u-ops resetting all > vars from that scope block? Yeah, wanted to say the same, I'm afraid such a change will very much affect debugging experience close to the end of inlined functions, as sinking, scheduling and various other passes may move statements from the inline functions across those resets. And, various tools and users really want to be able to inspect variables and parameters on the return statement. So, IMHO to do something like this, we'd need to mark those debug stmts some way to say that they aren't normal debug binds, but debug binds at the end of scopes (whether inlined functions or just lexical blocks), and optimization passes that perform code motion should try to detect the case when they are moving downward some statements across such debug stmts and move those debug stmts along with those if possible. 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, while your patch adds it unconditionally, even when debug stmts for those won't be really emitted. As they are just resets, that hopefully will not drastically affect var-tracking time, but might affect other optimization passes, which would need to deal with much more statements than before. Jakub