From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25373 invoked by alias); 18 Aug 2008 15:04:30 -0000 Received: (qmail 25363 invoked by uid 22791); 18 Aug 2008 15:04:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 15:03:54 +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 m7IF2om6018910; Mon, 18 Aug 2008 11:03:10 -0400 Received: from opsy.redhat.com (vpn-10-18.bos.redhat.com [10.16.10.18]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m7IF2b1O007937; Mon, 18 Aug 2008 11:02:37 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 473DE3782B7; Mon, 18 Aug 2008 09:02:43 -0600 (MDT) To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: RFA: shrink main_type References: <20080818130009.GM16894@adacore.com> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Mon, 18 Aug 2008 15:04:00 -0000 In-Reply-To: <20080818130009.GM16894@adacore.com> (Joel Brobecker's message of "Mon\, 18 Aug 2008 17\:00\:09 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00485.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> I'm not opposed to this sort of packing, particularly since this is Joel> something that we already do for other fields of this type, but I'm Joel> interested in the performance impact of such a change. A few hundred Joel> K of memory for cc1 doesn't sound like a lot nowadays. I wonder what Joel> it would cost and save for a program of the size of Mozilla... I will find out. I did not try to measure the performance impact. Any suggestions for a test case that would be measurably impacted by this change? I am not enough of a gdb expert to know what code would rely on access to these fields in a time-critical way. [ada] Joel> Another good observation. I will try to find some time to fix... Joel> I only saw a couple of instances (with TYPE_FIXED_INSTANCE). Did you Joel> spot any other? Yeah, there were just a couple, nothing major. Joel> Do the upper/lower_bound_type fields still "pack nicely"? Yes. Joel> This is where my knowledge of C (or lack thereof) shows up, but Joel> would the following declaration instead help the compiler? Joel> ENUM_BITFIELD(type_code) code : 6; Joel> ENUM_BITFIELD(type_flag_value) flags : 18; Joel> ENUM_BITFIELD(array_bound_type) upper_bound_type : 4; Joel> ENUM_BITFIELD(array_bound_type) lower_bound_type : 4; It wouldn't hurt, but I don't think it would help. Bit fields are just packed in as tightly as possible. If you have the "7 dwarves" installed you can easily see the layout by running "pahole --class_name=main_type". (FWIW it would be pretty easy to change gdb to give this info -- which is pretty handy.) Joel> Then, I don't understand why the two "short" fields have been Joel> moved up just behind the "flags" field (sorry, like I said, there Joel> are holes in my C knowledge). No problem. I moved these fields to preserve good packing on a 64-bit machine. Without this, there would be a hole between 'flags' and 'name', and another one where 'flags' used to be. Tom