This is the mail archive of the
mailing list for the GCC project.
Re: the size of tree_decl
- From: law at redhat dot com
- To: Dan Nicolaescu <dann at ics dot uci dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 14 Feb 2003 12:52:23 -0700
- Subject: Re: the size of tree_decl
- Reply-to: law at redhat dot com
In message <200302122025.h1CKPDkA024739@gremlin.ics.uci.edu>, Dan Nicolaescu
> > > 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.