Re: RFA: shrink main_type

Tom Tromey
2008-08-18T15:19:05Z

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> If you're going to do this anyway, why not make them individual
Daniel> bitfields? Would that be too disruptive?

It would not be too bad. I count 69 uses of TYPE_FLAGS, that isn't a
huge number. The other uses are hidden by the accessor macros.

I will make this change.

FWIW I only looked at this struct since it is marked as being
space-critical, and I saw a way to shrink it a bit.

Daniel> I don't think it's particularly useful to change the type of this to
Daniel> the enum since we don't put enum values in it, just bitwise
Daniel> combination of them. (Isn't that invalid in C++?)

Yes, it is invalid C++. Though... currently if you build gdb with
g++, you will get thousands of errors. One more wouldn't make that
project significantly harder IMO :)

Daniel> And if you want to repack the upper/lower bounds fields, I bet they
Daniel> can move into type_specific.

I looked at this. I am not so sure about moving these fields -- they
are referenced by pretty much every language. I didn't look at why
this was so (i.e., could be dead code, or bad cut-and-paste, or
whatever).

I was thinking that perhaps the vptr stuff could go in type_specific.
Or, we could do like GCC and have different structures depending on
the code, so that non-struct types don't have to carry around unused
fields. I didn't try to measure how much this would save. These are
bigger changes; this particular patch was just an easy way to save
some memory.

Tom