This is the mail archive of the gcc@gcc.gnu.org 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: Improving gcc scalability wrt _extra_ large C files


Neil Booth <neil at daikokuya dot co dot uk> writes:

| Zack Weinberg wrote:-
| 
| > Jacques THOMAS <jthomas at cs dot purdue dot edu> writes:
| > 
| > This sounds like a sane approach.  It's possible that you won't need
| > the linked list anymore if you make that change.
| > 
| > Another possible approach is to invert the lookup.  Make the
| > IDENTIFIER_NODE point to its binding contour, and then have lookup_tag
| > check that that's the one we want.  (handwaving wildly not having
| > actually looked at the code).
| 
| Why don't we just have three bindings to each identifier, corresponding
| to the 3 namespaces in the C standard (ignoring structure members):
| tags, normal decls and labels.  Then lookup is constant time.  That's
| what I've done in my c-parser.  I could never understand why we make
| name lookup so complicated (and slow) in the C front end.

Same song here.

With the following minor corrections for the C++ front-end:

   1) namespace scope
   2) class-scope
   3) function prototype scope
   4) template protototype scope (this one is not directly spelled out
      in the standard but is needed to implement correctly
      template-parameter declarations).  I dicthed the baroque notion
      of tag_transparent.
   5) local-scope:
        * for-scope, while-scope
        * try-scope
        * cacth-scope

I'm using a hashtable to implement bindings.  I've augtmented
ht_identifier with a new field to cache identifier's hash value.

-- Gaby


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