From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26272 invoked by alias); 18 Aug 2008 13:01:06 -0000 Received: (qmail 26258 invoked by uid 22791); 18 Aug 2008 13:01:05 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 13:00:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0583F2A9734; Mon, 18 Aug 2008 09:00:18 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4XUt+xX4A2o5; Mon, 18 Aug 2008 09:00:17 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 150EE2A96E0; Mon, 18 Aug 2008 09:00:17 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id EBF48E7ACD; Mon, 18 Aug 2008 15:00:09 +0200 (CEST) Date: Mon, 18 Aug 2008 13:01:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFA: shrink main_type Message-ID: <20080818130009.GM16894@adacore.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00478.txt.bz2 > This patch shrinks struct main_type 32- and 64-bit machines by > shrinking the type_code and flags fields and moving around a couple > other fields. > > On my x86 box, this saves about 1% of memory on "gdb -readnow cc1" -- > a few hundred K -- at the cost of slightly increasing gdb's text size. I'm not opposed to this sort of packing, particularly since this is something that we already do for other fields of this type, but I'm interested in the performance impact of such a change. A few hundred K of memory for cc1 doesn't sound like a lot nowadays. I wonder what it would cost and save for a program of the size of Mozilla... > I noticed that the Ada code does not use TYPE_FLAG_* consistently with > the rest of gdb (it tests the flags directly rather than using the > macros), but I didn't change this. Another good observation. I will try to find some time to fix... I only saw a couple of instances (with TYPE_FIXED_INSTANCE). Did you spot any other? :REVIEWMAIL: > 2008-08-17 Tom Tromey > > * gdbtypes.h (enum type_flag_value): New enum. > (TYPE_FLAG_UNSIGNED, TYPE_FLAG_NOSIGN, TYPE_FLAG_STUB, > TYPE_FLAG_TARGET_STUB, TYPE_FLAG_STATIC, TYPE_FLAG_CONST, > TYPE_FLAG_VOLATILE, TYPE_FLAG_PROTOTYPED, TYPE_FLAG_INCOMPLETE, > TYPE_FLAG_CODE_SPACE, TYPE_FLAG_DATA_SPACE, TYPE_FLAG_VARARGS, > TYPE_FLAG_VECTOR, TYPE_FLAG_ADDRESS_CLASS_1, > TYPE_FLAG_ADDRESS_CLASS_2, TYPE_FLAG_FIXED_INSTANCE, > TYPE_FLAG_STUB_SUPPORTED, TYPE_FLAG_NOTTEXT): Now enum constants. I think this change is really great, and can be checked in separately from the rest. > (struct main_type) : Now 5 bits. > : Move earlier. Now a bit field. > : Move earlier. I'm having trouble understanding the new layout that you propose. It looks like this: ENUM_BITFIELD(type_code) code : 5; /* Array bounds. These fields appear at this location because they pack nicely here. */ ENUM_BITFIELD(array_bound_type) upper_bound_type : 4; ENUM_BITFIELD(array_bound_type) lower_bound_type : 4; /* Flags about this type. This field appears at this location because it packs nicely here. */ ENUM_BITFIELD(type_flag_value) flags : 18; Do the upper/lower_bound_type fields still "pack nicely"? This is where my knowledge of C (or lack thereof) shows up, but would the following declaration instead help the compiler? ENUM_BITFIELD(type_code) code : 6; ENUM_BITFIELD(type_flag_value) flags : 18; ENUM_BITFIELD(array_bound_type) upper_bound_type : 4; ENUM_BITFIELD(array_bound_type) lower_bound_type : 4; Then, I don't understand why the two "short" fields have been moved up just behind the "flags" field (sorry, like I said, there are holes in my C knowledge). -- Joel