From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21377 invoked by alias); 17 Jun 2009 20:21:15 -0000 Received: (qmail 21365 invoked by uid 22791); 17 Jun 2009 20:21:14 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Jun 2009 20:21:07 +0000 Received: from sunsite.mff.cuni.cz (localhost [127.0.0.1]) by sunsite.mff.cuni.cz (8.14.3/8.14.3) with ESMTP id n5HKIgSQ023579; Wed, 17 Jun 2009 22:18:42 +0200 Received: (from jakub@localhost) by sunsite.mff.cuni.cz (8.14.3/8.14.3/Submit) id n5HKIfn3023578; Wed, 17 Jun 2009 22:18:42 +0200 Date: Wed, 17 Jun 2009 20:21:00 -0000 From: Jakub Jelinek To: Eric Botcazou , Richard Guenther , gcc@gcc.gnu.org, Alexandre Oliva Subject: Re: VTA guality assessment: better than -O0 ;-) Message-ID: <20090617201841.GQ3101@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <84fc9c000906130823yd6a6296x947a972c7d2535d5@mail.gmail.com> <200906132000.35949.ebotcazou@adacore.com> <20090613200839.GK3101@sunsite.ms.mff.cuni.cz> <20090614151732.GA10031@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090614151732.GA10031@caradoc.them.org> User-Agent: Mutt/1.5.19 (2009-01-05) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00422.txt.bz2 On Sun, Jun 14, 2009 at 11:17:32AM -0400, Daniel Jacobowitz wrote: > On Sat, Jun 13, 2009 at 10:08:39PM +0200, Jakub Jelinek wrote: > > I really think we need to do (limited) -fvar-tracking even for -O0, it is > > really bad that most arguments have wrong locations through the prologue, > > while at -O1 or above they often have correct location. > > We should just do the tracking inside of the prologue or for register > > variables, those that are stored into memory during the prologue and live in > > memory shouldn't be tracked outside of the prologue at -O0. > > I completely agree, this would make GDB more useful. --- gcc/var-tracking.c.jj 2009-05-04 16:46:38.000000000 +0200 +++ gcc/var-tracking.c 2009-06-17 17:48:58.000000000 +0200 @@ -1652,6 +1652,8 @@ track_expr_p (tree expr) if (MEM_SIZE (decl_rtl) && INTVAL (MEM_SIZE (decl_rtl)) > MAX_VAR_PARTS) return 0; + if (!optimize && TREE_CODE (expr) == VAR_DECL) + return 0; } return 1; decreased the -O0 -g -fvar-tracking debuginfo on the trunk quite a bit, I don't think there is any point in tracking VAR_DECLs that live in MEM, only PARM_DECLs (which during the prologue might move from registers) and VAR_DECLs that don't have MEM decl_rtl (at -O0 those are just vars with register keyword I believe from the ones var-tracking would track). Still, I think for -O0 -g -fvar-tracking we should note that the parms moved into their desired slots immediately (e.g. by pretending the register from which they have been stored was also clobbered on the same instruction). Jakub