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


It is indeed funny that we came out with the same analysis.

Please let me know if I can help.

Regards,
Jacques.

Gabriel Dos Reis wrote:

Jacques THOMAS <jthomas at cs dot purdue dot edu> writes:

[...]

| My idea for improving lookup_tag is to use one hash table per binding
| level, with entries pointing to the tags of the binding level. To do
| that I would modify push_tag so that it does insert the symbol in the
| hash table at the same time that it does insert it in the linked
| list. lookup_tag could then use this hash table to do faster lookups.

Funny enought, this is exactly the kind of work I'm currently doing.
Somes notes about my work

 1) I have deleted the two notions of binding-level and scope.
    They are replaced with the single notion of "scope" as per the
    C++ standard definition.

2) I'm using indeed a hash table to implement name lookup. To make
this efficient, I've augmented struct ht_identifier with a new
filed "hash_value" that caches the hash value computed by hashtable.c:calc_hash()


However, what I've seen so far is that this results into a large
amount of code being touched or restructrured.  I'll post a patch
mainline once I've resolved a couple of regressions, then I hope we
will see which parts can be safely backported to 3.3

At any rate, your analysis matches mine on the issue that GCC/g++ is
spending an excessive amount of time in name lookup.

-- Gaby





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