This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC/RFHelp: c-decl.c rewrite - almost but not quite

Robert Bowdidge <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]