From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11733 invoked by alias); 1 Jun 2009 19:23:22 -0000 Received: (qmail 11725 invoked by uid 22791); 1 Jun 2009 19:23:22 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Jun 2009 19:23:16 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n51JNCZX023014; Mon, 1 Jun 2009 15:23:12 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n51JNBTX001243; Mon, 1 Jun 2009 15:23:11 -0400 Received: from freie.oliva.athome.lsd.ic.unicamp.br (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n51JN9Xm003370; Mon, 1 Jun 2009 15:23:10 -0400 Received: from free.oliva.athome.lsd.ic.unicamp.br (free.oliva.athome.lsd.ic.unicamp.br [172.31.160.1]) by freie.oliva.athome.lsd.ic.unicamp.br (8.14.3/8.14.3) with ESMTP id n51JN8Sh014400; Mon, 1 Jun 2009 16:23:08 -0300 Received: from free.oliva.athome.lsd.ic.unicamp.br (localhost [127.0.0.1]) by free.oliva.athome.lsd.ic.unicamp.br (8.14.3/8.14.3) with ESMTP id n51JN8jU005721; Mon, 1 Jun 2009 16:23:08 -0300 Received: (from aoliva@localhost) by free.oliva.athome.lsd.ic.unicamp.br (8.14.3/8.14.3/Submit) id n51JN5Lc005720; Mon, 1 Jun 2009 16:23:05 -0300 To: Andrew MacLeod Cc: Ian Lance Taylor , gcc-patches@gcc.gnu.org Subject: Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables References: <4702B1C0.80807@redhat.com> <4A24114D.1000006@redhat.com> From: Alexandre Oliva Date: Mon, 01 Jun 2009 19:23:00 -0000 In-Reply-To: <4A24114D.1000006@redhat.com> (Andrew MacLeod's message of "Mon\, 01 Jun 2009 13\:35\:09 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2009-06/txt/msg00106.txt.bz2 On Jun 1, 2009, Andrew MacLeod wrote: > Is there a reason we can't leave the current default behaviour the way > it is, and have the VTA code simple enable the "best" choices for it. We don't want options used to control generation of debug information (say the option that enables or disables VTA) to change the generated code (say enable or disable coalescing), do we? This would be as bad as -g/-g0 generating different code. Personally, I don't see the point of the options either, but I don't see the point of the current trade-off either. Corrupting debug info only for inlined variables is not really better than corrupting debug info uniformly. I'd much rather we optimized as well as we could when asked to optimize (would save compile-time memory and time too), and take care of preserving debug information through adequade debug information infrastructure. But this would imply changing defaults, and would make it difficult to compare the performance effects of the additional coalescing. Or, leaving the default as they are, trivial testcases (little to no inlining) might give an impression that current debug info doesn't suck as much as it does, reducing the pressure for better infrastructure. -- 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 Brazil Compiler Engineer