This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: shrink main_type
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 18 Aug 2008 09:02:42 -0600
- Subject: Re: RFA: shrink main_type
- References: <m37iafzdcp.fsf@fleche.redhat.com> <20080818130009.GM16894@adacore.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> 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