From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28121 invoked by alias); 18 Nov 2005 06:24:35 -0000 Received: (qmail 28096 invoked by uid 22791); 18 Nov 2005 06:24:33 -0000 Received: from dumbledore.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.11) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 06:24:33 +0000 Received: (qmail 30094 invoked from network); 18 Nov 2005 06:24:31 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Nov 2005 06:24:31 -0000 Message-ID: <437D7395.8080000@codesourcery.com> Date: Fri, 18 Nov 2005 06:24:00 -0000 From: Mark Mitchell User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Richard Henderson CC: Aldy Hernandez , gcc@gcc.gnu.org Subject: Re: pruning unused debugging types (enums/PR23336) References: <20051117220835.GA8907@redhat.com> <20051117230925.GB21279@redhat.com> In-Reply-To: <20051117230925.GB21279@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2005-11/txt/msg00824.txt.bz2 Richard Henderson wrote: > A solution that comes to mind is to have the front-end add dummy > TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most > BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and had > no DECL_NAME, it'd be easy for us to notice that we shouldn't > actually emit debug info for the TYPE_DECL itself, but that we > should consider its TREE_TYPE to be used. > > I'm open to better schemes. Perhaps a used-type hash table in > the struct function. I like the idea, but I think a hash table would be better. In fact, I think the best choice would be a hash table during compilation of the function, transformed into a vector after the closing brace of the function, so that we do not have the wasted memory associated with either dummy TYPE_DECLs or hash table entries. Also, we should do this only for the kinds of types we tend to lose (maybe casts and enums?), to keep the extra memory cost to a minimum. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304