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: the size of tree_decl


In message <200302122025.h1CKPDkA024739@gremlin.ics.uci.edu>, Dan Nicolaescu 
writes:
 >  >  >  tree vindex;  -- seems to be only used in C++ and java
 >  >  >Can it be moved to the language specific part of the decl?
 >  > Hmm, I'm somewhat surprised it's not used by Obj-C.  No strong
 >  > opinions here.
 >
 >I am not too sure, I just grepped for vindex, and there were no hits
 >in the objc directory...
Again, I'm just surpried.  I thought Objective-C had virtual function
calls.  It's possible they're implemented without using vindex.

 >There's another field that is too big: location_t locus, it contains
 >a line number and a char*. If it was to use logical lines like cpplib
 >does, the char* 
Yup.  locus information can be a significant hog. 



 >Some numbers to show why keeping tree_decl small is important. 
 >cc1 -O2 combine.i 
No surprise there.  We *know* decls are a huge amount of the memory
consumed by the compiler.  In the back of my mind I keep thinking
that we should be able to make more sense of the zillions of fields
in DECL nodes and possibly break out some things that don't make
sense.  I also get the sense that we over-use decl nodes for things
that really aren't decls -- if I remember correctly all the "statement"
nodes in the C front-end are implemented as DECLs.  Ugh.

Jeff



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