This is the mail archive of the
mailing list for the GCC project.
Re: RFC/RFHelp: c-decl.c rewrite - almost but not quite
Robert Bowdidge <firstname.lastname@example.org> writes:
> On Mar 17, 2004, at 6:22 PM, Zack Weinberg wrote:
>> How's that?
> I am now seriously enlightened. Thanks for writing all that down -- I
> now realize part of the reason I didn't understand the code was that I
> wasn't aware of some of the details of C's semantics -- specifically
> the different namespaces for tags, labels, and names.
I will try to clarify this.
> You've also made me realize that a potential optimization I noticed
> might not be so bright. When talking with Geoff Keating and Matt
> Austern about the stree work, we were looking at the cxx_binding
> structure. I asked why there was both a field for name and type, and
> Geoff explained how that handled the "struct stat" problem from C
> code. I'd suggested at the time that most cxx_bindings would only have
> one field filled at a time, so figuring out an alternative scheme
> (such as placing the type in a new cxx_binding chained off the old
> one) could save us about 1% on gcc's memory use. Considering that
> you've done the reverse (going from a chained representation to a
> structure containing all fields defined at the same level), maybe
> changing cxx_binding isn't an improvement.
I don't think I've exactly done the reverse. What I've done is
introduced a layer of indirection between the identifiers and the
decls. What you are describing sounds like my possible memory-saving
trick - have just one chain of c_binding structures off the
IDENTIFIER_NODE; lookup has to dig through the list to find the
relevant one. I do not know a priori whether this will be an
improvement; it has substantial code complexity costs, but the common
case would use less memory and might go faster. It needs to be
benchmarked. I plan to try it, but in isolation from all other
An advantage of this idea is that it could be naturally extended to
handle FIELD_DECLs, which are currently stored in secondary data
structures with not-very-efficient lookup.
I realized this morning that I was stuck with the ->id field of struct
c_binding mainly because of error handling. Most entities that get
bound to identifiers have a field in the tree that points back to the
name (DECL_NAME, TYPE_NAME). error_mark_node doesn't. I need to be
able to get back to the name from the c_binding structure in one
place: pop_scope. Possibly it makes sense to allocate a dummy
VAR_DECL instead, when an undeclared identifier is encountered, but
that has the possibility of producing weird error cascade issues.
Need to think about that more.